Learning C with the Amiga

[Cymric]

mel_zoom wrote:
My question is, which one should I be using? The last one seems pretty explicit but Im told that its the best one to use even though the first one is in the K&R book as the principal definition :-?

For this sort of question I refer you to the excellent and witty C-faq, which in this case states that the correct declaration is at the least

int main() { }

or

int main(void) { }

to tell the C-compiler (though not a C++-compiler!) that you're not expecting any arguments to main(). (The C++-compiler is a bit more literal and sees the above as two different functions: the first doesn't expect any parameter, the second expects a parameter of type 'void'.) If you do want arguments, then the correct declaration is

int main(int argc, char *argv[]) { }

The upshot is that you should end main() not with a plain 'return;' but with a 'return ;'. The integer is usually 0 to indicate that the program completed succesfully, if you set it to 5 or 10 AmigaDOS interprets this as a warning, and with 20 or higher it creates an error message. (I think, it's been a while .)

To make things a bit more complex: the above mechanism works only for programs you start from the CLI. For programs which start from the Workbench, you will need to use a different and much more Amiga-like mechanism. For now you can ignore its existence, but remember that you need to perform a bit of special processing if you want your program to be double-clickable.

[Cymric]

Karlos wrote:
Wrong again. Constant items (pointers included) may be allocated in write protected pages of memory on some implementations (ok, not amigaos), physically preventing it from being altered after it has been assigned.

Quite true. The following code will run happily on an Amiga:

Code: [Select]

   char *s = "Hi!";
    ....
    s[1] = 'a';
    ....
   
but will crash on a Unix computer because the string 'Hi!' is saved in memory which cannot be written to. The program will crash with a 'segmentation fault', a sure indicator of the program poking in memory where it shouldn't be. The problem is that there is nothing wrong with the above code: it's the implementation by the compiler which fscks things up.

[Cymric]

mel_zoom wrote:
lou_dias:

"It's these quirks that make it not a good language for beginners. Maybe if she ever learns a second language (C++ doesn't count), then she'll see the light at the end of the tunnel."

Hmmm.

You seem to think that I am lost in a dark tunnel. Im not - C seems quite straightforward so far. Whats this "light" am I supposed to C? :-P

" C is a language with few rules. How do you write structured code when the language has no uniform structure within it's design. "

It seems quite structured to me.

The problems are not what you think they are, and will only surface once you begin to construct bigger programs which cover, say, more than 25 K of source code. Then you will find that the parsimonity of C can become a hindrance rather than an asset:

- there is no automated memory management, forcing you to keep meticulous tabs on what your program does with what memory---and believe me, this is much harder than it looks
- type checking is enforced by the compiler and not the language
- string handling pretty much sucks: all you have is an array and a few library functions like strcpy() and strlen()---writing code which does a lot of string processing is not fun this way
- there is no bounds checking on arrays, so you can easily do 'int a[10]; a[10]=9;' and then try to find the cause of these spurious crashes of your program
- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth
- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about
- and a LOT more.

The picture I'm trying to paint here is that C is an exceedingly basic language offering very little programming comforts or standardisation. You must provide quite a lot of extra layers to keep your programs managable, and none of these contribute to the actual program you want to write. You require a reusable code library which does all this boring stuff so you only code this once, test it to death once so that you're sure it's rock-solid and nuke-proof, and then use it more religiously than a fundamentalist clings to his scripture. But even that is not so easy as it looks because you now face the problem of modularity---breaking up code over various separate parts---and C's approach is rather basic.

In this regard I agree with lou_dias that C might not be the best language to learn to program in. It's not that the basics are difficult or in any way 'wrong': it's that once you master the basics that you are exposed to a lot of bare machinery you can really do without. Strangely enough, books and tutorials never cover this particular aspect...  :-P

[Cymric]

*Sighs*. Of course I could have known I was going to be misunderstood. The point I was trying to make is that although C might be flexible (which is your point), as a [size=18]BEGINNING CODER[/size] you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book. Keep those words [size=18]BEGINNING CODER[/size] in mind when reading my response please, and don't see it as a critique of the language---although one is forced to admit that if one has written a few projects in Python, or Ruby or Pike, C seems awfully messy and exposed.

That was my official answer. Now as to my unofficial one, which I will not debate further, because it does not cover what I meant to convey.  

* Pointer stuff is prone to errors, no doubt about it. If you've been able to code a general n-dimensional matrix allocator without the code barfing up once (which is the kind of memory allocation I had in mind), then I bow to you, my Master, and will come train with you to learn the ways of the Force.

* String handling via IS messy if you've grown accostumed to simple things like 'a = a + ", world!";'  With first you'd have to allocate the memory to hold the longer char *a, then copy it over with strcpy(). That's a whole lot of extra typing just for something simple as string concatenation. And that's just the beginning. Look up the capabilities of Python's string module if you want to have a useful set of routines which are not provided by ! Of course, you can easily write them yourself in C---but that was my original point.

* Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated. You are always poking around in memory you are not supposed to be poking around in. There is no language-supported checking on this type of error, which was again my point. Perhaps you are not such a good teacher of the ways of the Force after all...

* As to the system dependent stuff: If I want to code something which uses threads, and has to run on an Amiga, Windows, and Linux, I'd have to write separate threading modules for use with each operating system. Doable of course. But if I were to use Pike or Python or Java, I have but one way of writing that code to worry about, which (you guessed it) was my point. I'm not saying that the implementation of said languages on said OSes is the same (it's not) or easy (which it's not either)---but for the beginning coder it sure would be a lot easier if it were just all standardised, right...?

[Cymric]

mel_zoom wrote:
cymric:

I may be a beginner but I do understand that C is low level. Im not about to give up if I run into a problem handling an array.

That's perfectly okay, you need some persistence in order to learn programming in any language save for perhaps one: DWIM, Do What I Mean. You're perfectly fine with momentarily forgetting what I wrote as well---but remember that I wrote it once you begin coding big projects, and that you will require lots of extras to keep those managable. For now, concentrate on the basics, and even more importantly, enjoy yourself :-D.

@Piru:
Yes, using libraries is of course the way to go with C, I'm not at all disputing that. I'm also not trying to woo you away from your C-compiler: I too am very fond of my little blurbs of C with all their idiosyncracies, although I'm not experienced enough to do rapid prototyping with the language. I need something like Python etc. for that.

[Cymric]

Applications vary. I've had to code more text parsers to read out so-called universal file formats of weird scientific equipment than I care to remember.