Learning C with the Amiga

[Karlos]

@Cymric

I've had to do a lot of text parsing too and even then I rarely needed to concatenate strings. There are usually solutions you can come up with that don't require endless reallocation and strcat ;-)

[falemagn]

@ Cymric

Why would a text parser need to concatenate strings?

[Karlos]

falemagn wrote:
@ Cymric

Why would a text parser need to concatenate strings?

My point exactly. All the parsing I've done, if anything usually involved breaking text up into smaller tokens, not concatenating them into larger ones.

[Louis Dias]

Karlos wrote:

falemagn wrote:
@ Cymric

Why would a text parser need to concatenate strings?

My point exactly. All the parsing I've done, if anything usually involved breaking text up into smaller tokens, not concatenating them into larger ones.

So you've never built SQL statements on the fly based on parameters in a filtering selection screen for a program that generates a report?

[falemagn]

lou_dias wrote:

So you've never built SQL statements on the fly based on parameters in a filtering selection screen for a program that generates a report?

And that's text parsing exactly in which way?

On the costructive side: yes, in those cases - which however have nothing to do with parsing, the standard C library string functions are a pain to use. However, you can use whichever string library suits you best, or even not use C but rather C++.

[Karlos]

Precisely.

That's not parsing text, that's building text. String concatenation may be a viable option there, but even then there are other solutions.

Most database stuff I've had to do that wasn't from a basic LAMP/ASP perspective has all been in C++ anyway and there the basic string class has proved more than adequate for said purposes.

[Louis Dias]

Ok, I've written code that parses a file and replaces one text/byte(s) code with another.  Now in VB6, you can read a 2MB file into a string, in memory, and doing a simple replace all at once and then writing over the old file was much faster than the traditional line by line method of drilling through the file, while writing to another followed by the delete of the old one and rename of the new to match the old.

It came in handy when converting large .CSV files with lines terminated with CR to CR/LF and vice versa.

File access is slow compared to memory access, hence having the entire file in memory was ideal and VB's "Replace" command allows you to use any sequence of bytes.  It's not just limited to 7 bit ascii.

This turned a batch processing job of many large files into one that went from taking over an hour to taking just several minutes.

[Karlos]

@lou_dias

#include

More search/match/replace power than you can throw a very large stick at ;-)

[amipal]

@adz

The C Programming Language (ANSI C) - B.W. Kernighan & D.M. Ritchie

I've been recommended this book also, so I picked up a copy from eBay - much better than the "C for Dummies" book I used initially. However, I haven't looked at it  since this time last year!

Time to get back into it methinks... :crazy:  ;-)

[voxel]

@ mel_zoom :-)

Hi :-)

There is a good list where you can ask for advice in learning C, that is open to all be they beginners or pros :-), and is sp*mfree, I'm it's moderator in chief ;-)

This list count some of the best Amiga coders and they will be happy to help you, so why not apply to it?

You can go there : Amiga-C2 mailling list and push the "join" button :-)

[CannonFodder]

lou_dias wrote:
Ok, I've written code that parses a file and replaces one text/byte(s) code with another.  Now in VB6, you can read a 2MB file into a string, in memory, and doing a simple replace all at once and then writing over the old file was much faster than the traditional line by line method of drilling through the file, while writing to another followed by the delete of the old one and rename of the new to match the old.

It came in handy when converting large .CSV files with lines terminated with CR to CR/LF and vice versa.

File access is slow compared to memory access, hence having the entire file in memory was ideal and VB's "Replace" command allows you to use any sequence of bytes.  It's not just limited to 7 bit ascii.

This turned a batch processing job of many large files into one that went from taking over an hour to taking just several minutes.

Why use VB to do the job of PL/SQL(T-SQL etc)?

Anyway, isn't this thread supposed to be about learning C?  What point are you trying to achieve by spamming it with off topic crap about how superior VB is?

Start another thread and discuss it there.

[mel_zoom]

cannonfodder:

Perhaps he is trying to tempt me into VB coding :-)

[CannonFodder]

mel_zoom wrote:
cannonfodder:

Perhaps he is trying to tempt me into VB coding :-)

Well if we are all playing that game.  Learn PL/SQL, you'll get paid more. ;-)

[mel_zoom]

Nobody seems to get this. Im learning for my own interests, to be better qualified to deal with some of the technical jibber jabber I come across in my work and most of all - for fun!

A lot of SQL is used where I currently work - several implementations used across a range of systems. The one thing they all have in common is that they are overwhelmingly boring!

[CannonFodder]

mel_zoom wrote:
Nobody seems to get this. Im learning for my own interests, to be better qualified to deal with some of the technical jibber jabber I come across in my work and most of all - for fun!

A lot of SQL is used where I currently work - several implementations used across a range of systems. The one thing they all have in common is that they are overwhelmingly boring!

Shall I start another thread?

"Why PL/SQL is not boring" ;-)

[mel_zoom]

If you must. I am thinking I will have to start a new thread if I want to ask questions about C coding. This one seems to have gone off all by itself :lol: