Learning C with the Amiga

[Jupp3]

Ive decided to have a go at learning C on the amiga. I do know a little bit about the language and programming in general but Ive never really written anything.

That's a good idea. I also like the idea of starting to learn with C. Many people say they'll "start straight from C++" when many (including me) think that it's a good idea to learn the basics in C.

Of course that doesn't mean you would HAVE to move to C++, that's up to you. You can do in C everything, you can do in C++. And actually, I found C to suit my needs so well, that I never really thought of moving towards C++. I nowadays write C-code at work aswell.

At first it might be best to not go further than doing some simple shell programs (another thing you did right imho :-)), but then you should ask yourself what you want to do really?

Is it programs? Is it games? Is it something else?

And especially with games, you must decide what kind of games you would want to do. 3D (3D accelerated or not), 2D (system window or fullscreen, AGA or gfx-cards-only)

Personally I started using SDL and OpenGL. Both of them make many things so much easier. To be honest, I was surprised how easy it was to do simple 3D graphics with OpenGL. SDL is a bit more complex, but also makes many things (such as graphics, sounds, input handling etc.) much easier. Of course the bad news is that with both you can count out all <=AGA users but if you don't, you will be seriously restricting what you can do :-)

MorphOS has quite good SDL and OpenGL support, and I think OS4's support isn't probably all that bad either (currently there's no shared SDL library, and OpenGL isn't as "complete" as MorphOS equivalent, but it's just a matter of learning what functions to (not) use).Classic amiga version of SDL is not that good, but works. OpenGL, however, is about the same as currently on OS4, but obviously requires 3D card for any serious use (as it does on ANY system anyway)

Oh, did I mention that both SDL and OpenGL are available on many (mainstream and non-mainstream) platforms? :-)

If you are interested, I can paste links to some tutorials I found helpful.

Oh, and welcome here, I think I forgot to say that in the other thread :-)

[Jupp3]

I should add that, IMNSHO, anybody that knows C and doesn't think it's worth making the jump to C++ either hasn't understood what OOP actually is and how it applies to any non-trivial project or hasn't realised just how much easier C++ can make many problems in C appear.

However in MY opinion, OOP is a "way of programming" that can be applied to ANY programming language, even to assembler. Of course some languages (not C++, imho) force you into OOP style.

I like C becouse in my opinion it's easier to think "what kind of code the compiler will produce", something that many people would argue, that it doesn't matter at all anymore. C is definitely better for REALLY small projects (talking kilobytes of compiled code here) and in the end it's up to you which ever programming language YOU prefer.

Both SDL and OpenGL were created to be used on C (but it's obviously possible to use them with other languages aswell)

And last but not least, my current work project is in C :-)

[Jupp3]

Question 1

Is there a way that a function can return more than one value simultaneously? Its obvious from the function definition syntax so far that you return a single value or nothing at all (void).

I read the thread quite quickly, and I'm not sure if this was already mentioned. At least there were some talks about pointers to structs, which are quite widely used.

Anyway, you can give function pointers to a variable.

For example:
void ChangeXandY(int * x, int * y, int xdiff, int ydiff)
{
    *x+=xdiff;
    *y+=ydiff;
}
int main(void)
{
    int x=4;
    int y=5;
    ChangeXandY(&x, &y, 1, 2);
    return x+y;
}

Doesn't make much sense, but demonstrates one way to do what you asked. Might not be the best way to achieve ">1 return values", but it's good-to-know, not least becouse it's used often in f.ex. OpenGL and SDL.

Also if you use pointer as argument but don't want to change the data, you can add "const" so that the compiler will warn you if you try to do that ;-)

With struct, you can just do like this:
void somefunc(struct somestruct * data)
{
    int x;
    x=data->intvalue;
}

Oh, if you end up using structs a lot (and even if you don't), it's a good idea to learn typedef early on, that would have saved me lots of code editing later on :-)
You can do f.ex.
typedef struct
{
    float x;
    float y;
    float z;
}Point3D;

And later in code, instead of doing something like this:
struct Point3D point;

you can do this:
Point3D point;

At least I find it more "clean" way to "say the same thing in C code"

[Jupp3]

In my opinion there's far more to document what's mentioned here...

Obvious stuff, such as function input & output value descriptions and their possible limitations. What kind of values functions should NOT be used with (even if it's practically impossible to end up with such values in CURRENT project (thus no need for error checking in that project), I've sometimes just copypasted some function to new project, just to find out that it doesn't work becouse I use values slightly different than I should)

Also, I consider some kind of changelog (what was broken and when, you know :-)) code documentation

Oh and last but not least, BUGS. Sometimes you just can't find a bug (but know a workaround), maybe some API you use has some nasty bug you can't fix. Personally I sometimes keep not-so-well-working code in my project for a while before starting to fix it to a better form - Maybe the whole idea isn't as great as I though (can't know before I try it for a while), or I just lack time to fix it for time being, and leave it for later. And thanks to documentation, I have one excuse less for forgetting it :-)

[Jupp3]

- 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

and believe me, I have done it, and it isn't THAT hard.

Actually I like it better than trying to guess what would be freed and when (Java garbage collection, for example)

- 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

Weird. Last time I checked there was stuff like character searching, string searching, string compare, string copying and joining etc.
Are you sure it's the same string.h we're talking about?

Of course you might need some more "advanced" stuff in few projects you make, but you can do pretty much with those functions, and they're useful for creating your own.

While we're discussing strings, one tip:
Never do for(i=0; i

- 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

Most likely becouse there isn't difference between dynamic and static memory allocations. And memory allocations is what strings are. So in some cases it would work, in some it wouldn't.

- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth

Not every system is similar. Many systems don't even have any graphics abilities at all, or they differ a lot. How would you create an uniform graphics api, that can draw for example AGA planar graphics and 32bit true color graphics?

Not really a feature, but this is one thing I really like about C. It doesn't try to force you to use some certain functions for (f.ex) graphics. You can just pick one that works best for your project, or do one of your own. You can use system-dependant API (DirectX, Direct3D) or one that's cross-platform (SDL, OpenGL), the choice is yours, not the choice of the developers of the programming language, you use.

- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about

Just like earlier, this is highly system dependant stuff. Some systems support threading, some do not. Different threading implementations are, well, different. Some offer more options than the others, so what kind of common API would you create?
Again, C doesn't force any particular solution you. you can pick any you like. Most of them "fit in" C code very nicely.

[Jupp3]

as a BEGINNING CODER you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book.

So what? Just use libraries that are suitable for beginners. Examples of such would be (imho) SDL and OpenGL.

But indeed that IS a problem. Many "beginner books" only have simple maths, basic structures, argument handling (overall, shell-only stuff) - all that while there are relatively easy ways to actually get (for example) graphical output of what you can calculate in your code!

I admit, "not being able to see what I could calculate" was maybe my biggest problem when I started coding in C, so in the beginning I just used a CU Amiga tutorial as base. It had code, which could actually draw pixels in window :-o - didn't understand most of it back then, but I managed to make it "do something I could see"

Soon that expanded to something, that should draw sierpinski triangle in a window (and later it actually DID draw that, once I replaced if(a=1) etc. with if(a==1), later switch-case, obviously)

Second problem was that I was using StormC back then, and it wouldn't compile much example codes I had. Later I just replaced it with gcc and separate text editor, and suddenly most of my problems just disappeared :-)

Since then it was OpenGL, then a bit of SDL and I noticed I had all features (and more) I always liked in AmosPRO, without all the problems.

Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated.

Consider following code (as code it sucks, but highlights the problem):

char *chr=malloc(atoi(argv[0]))
chr[10]='a';
There's no way compiler would know what size allocation ends up, so it can't warn about out-of-bounds access.

EDIT:
Maybe you meant that code should be checking bounds every time data is accessed, and compare it to the size of allocation? (thus forcing additional slowdown to all memory read & write operations)

Well that indeed can be a problem for beginners (especially considering how C does indexes, a[max] -> 0<=index
Again imho something, that shouldn't be forced on everyone. But I admit it, it can be a small problem for beginners.