Learning C with the Amiga

[AJCopland]

@Karlos
 :roflmao:

[AJCopland]

I'm always so wary about posting my code comments as I do this for work but always screw up when not in front of a compiler! Also I've been coding in C++ for the last couple of years and my C isn't strictly ANSI compliant anymore ... end disclaimer there :-D here goes.

1) A function can only "return" a single item. However that item can be a composite such as "struct", a pointer to other information, a reference to another item that does exist or a value.
This is where I might screw up the C vs C++ syntax btw. You don't need to pass in pointers to a function to change their value instead you can pass by reference.

for example:
// you could package all of your return values up like this.
typedef struct compositeItem{
float theHamster;
int downTheStream;
int unrelatedGubbins;
};

//and then your function would return like this.
compositeItem someDumbFunc()
{
compositeItem bodge;
//do funky things that fill compositeItem here
return bodge;
}

That would be one really bad way of doing it :-D instead you can pass by pointer or by reference.

void SonOfDumbFuncPointer( compositeItem *pCompItem, int *pVal )
{
// dereference the pointer to access the values location
(*pCompItem).theHamster = 0.0f;
(*pCompItem).downTheStream = *pVal;
(*pCompItem).unrelatedGubbins = *pVal;
++(*pVal);
}

void SonOfDumbFuncRef( compositeItem &rCompItem, int &rVal )
{
rCompitem.theHamster = 0.0f;
rCompitem.downTheStream = rVal;
rCompitem.unrelatedGubbins = rVal;
++rVal;
}

2) Arrays and pointers are, well ok they're not something to be shied away from in C or there's no point learning the language. You're correct in that the elements of an arrays can only be of one "type". That type can be made of either the language defined base types or your own.
See here for a reasonable explanation. Actually I could have skipped all of the above if I'd thought of this sooner :idea: Passing Parameters

3) You might pass a structure to erm... I dunno, serialise it for lobbing over a network? No, I dunno. If I pass a structure I usually pass by reference or pointer and make it "const" if I don't want it to be modified. I'm sure that there's some really awesome and intelligent reason for passing a structure by value, that... y'know, someone that knows and will seem obvious once they mention it :-D


Hope that didn't confuse things more.

Andy

[AJCopland]

@Karlos
For modifying things I usually manually dereference the root of a pointer hierarchy but for nested pointers I won't bother.

So for example:
(*ptr).myNestedStruct->ptrWithinStruct = NULL;

is as valid as:
ptr->myNestedStruct->ptrWithinStruct = NULL;

but... I just like it really because I see right at the start of the line what I'm doing. One of the guys I'm working with hates me doing it so I've done it less for this current project.

of course that should really have been:
assert(NULL!=ptr);
(*prt).myNestedStruct->ptrWithinStruct = NULL; :-o

[AJCopland]

@lou_dias
I've heard people describe C as a better assembler, but that doesn't make it a poor language to learn. As for imposed structure, well, I dislike imposed structure and I don't think that it teaches you to program well.

I've blown my own foot off in C more times than I'd like to imagine (C++ will let you take you're whole leg, and re-use the bullet :-D), but I think that learning how to write code so I'd avoid doing that again was a valuable lesson in itself.

You write structured code in the way that you present information, and by hiding functions in ".c" files so they only have local scope.
You preserve the intention of functions by enforcing "const" correctness, and by programming by contract. I.e. You assert that something is true at the beginning (You're input data is within ranges you expect and is valid) and that it has changed within the expected way within the function you've written at the end.

You can create libraries which hide the implementation of features you need throughout a program without giving others the ability to modify the underlying code, at least not without accessing that libraries source code directly or building their own.

Now that should teach you to structure code. By structure I mean that you'll make a conscious decision to implement things in a particular way and in a methodical manor as opposed to other languages where you implement things in a certain way... because it's the only way that the language will let you.

Andy

[AJCopland]

@lou_dias
Well I didn't give her the idea to use C but I'm sure that Mel has good reason :-) Indeed it matches my own viewpoint that C is a good starting language though.

The trouble with learning in some languages are that they force you to think in a certain manor. That's partly because it is the only way that language can do something. C has this to some degree as well (it is still a language and so that's unavoidable) but if you want to go down a particular route it'll pretty much let you and assume that you know what you're doing. I think that's a good thing because it means you have to plan, or at least think, about what it is that you're trying to do.

Going from a relatively unstructured language like C that lets you do some incredibly stupid things and just assumes that you know what you're doing, to another language that is more restrictive can be very frustrating because of the feeling that you're being locked into it's way of working. Conversely however, going from a more restrictive language to C can not only be daunting because of that freedom, it can also be unproductive because you won't know how it can be used and you'll end up using in the manor of the more restrictive language you came from.

This is not to say that C is the greatest language ever or anything. It has pitfalls and problems. I think most of my bad habits came from years of hacking in C before I learnt C++, but it's a very widely used base. The knowledge that Mel gains from learning C will be transferable to almost any other mainstream (where mainstream means a language you're likely to encounter in business) language Higher or Lower level and to any platform which is something that cannot be said for anything else, even C++ compilers aren't available on/for absolutely everything.

It looks like the place the Mel works at uses C++ so getting a grounding C first then moving onto C++ before you can develop some nasty habits might be my only real advice from all this btw :-D

Damn I'm at work not meant to be replying on here!

Andy

[AJCopland]

@Karlos
AArgh, yes I saw something just like this the other day in a render loop of all places :crazy: I was helping out a friend who's at Uni' with her group project trying to figure out why it ran so slow. The other problem is that because they're so used to Java they expect everything to be garbage collected auto-magically and were leaking almost a megabyte a frame!

That's not a comment against Java which is fine in my book, but does quite nicely demonstrate what I meant about going from a higher level language which has taught you one thing to a lower level language which doesn't support it :-D

Andy

[AJCopland]

@falemagn
Yeesh, yuck and no! :-x

That kinda code is itself a comment as it's a simple assignment, but what are you going to use it for and what is the number 2 representing? Bad commenting.

/* integer variable 'aIdx' is used in the following loop to iterate through mini-game actors updating them. Has initial value of 2 because first 2 entries are player 1 & player 2 */
int aIdx = 2;
for( ; aIdx < numMiniGameActors ; ++aIdx )
{
MiniGameActors[aIdx]->update(deltaTime);
}


That is a mildly spurious example, but it IS still a more valid example. Someone else will read your code, probably you, in 6 months time and be glad that you documented why you used the value 2. Also renamed 'a' to 'aIdx' to more clearly indicate that it is used as an index.

You're never writing code just for yourself, you're writing code for you in 6 months time as well. Not only that but it's good practice to comment why you did something so that when you are working on a group project you don't forget to do it for others who might be less experienced than you. (I see this lack of *why* comments everyday on the current project, it slows down work and is poor coding style).

Andy

[AJCopland]

@falemagn
I didn't mean to sound like you don't know what you're talking about, I'm merely at work and brevity matters when I'm replying. Sorry.

No my example wasn't ideal because I literally copied your example and expanded on it ever so slightly. However as you say you've been coding since you were 6. We have coders who have just graduated and hadn't touched a compiler until they hit Uni'.

Code wholly without comments won't do. We have a good set of guidelines here about what to comment and why (comment the purpose and usage for a class but not how for example), but I find your guidance that comments are pointless doesn't reflect what the less experienced coders have to deal with. That's why I suggest that over-commenting is better than under commenting.

Over-comment and everyone gets the bloody idea whether they want to or not. Under-comment and there's a chance that someone won't when they really really need to.

Andy

[AJCopland]

@falemagn
Ok, just so we're clear I agree with pretty much every point you've made.

The misunderstanding comes from the line:

The only things that require comments are algorithms, but the more self-documenting code you are able to write, the better.

Which in my haste this morning I totally missed. I'd personally extend that to include classes, structures, the usage of templates and a few other bits n' pieces that trip people over.

The idea of self commenting code is good, and all your points seemed valid, but having helped people through very well "self documented" code I still prefer to place comments to at least give them a secondary perspective. I also remember being a junior coder lost in "self documented" code and cursing the black heart of whoever wrote it for NOT leaving comments! So usually before a complex method I'll give a few lines description of the purpose of that method, the expected ranges and/or condition of it's inputs and expected outputs. It just helps people see what you're intention was.

I'm currently working on a project that has been outsourced to my company. The only comments in this code base are around equations in the physics library. Even though I've been doing this for a good 11 years now an undocumented interface is merely a hassle, but to someone else it's a quagmire that hinders development and can encourage lazy development practices.

Whilst C is a very precise language it isn't most of our coders "first" language. Over here that's English and so when people read my beautiful code :-D I like to tell them my purpose in writing it as well...

... plus comments give Babelfish something to work with, there's nothing worse than receiving a code base entirely with Japanese comments, variable and function names :crazy:

Andy

[AJCopland]

@NattyNoh
Was that a bizarre attempt at humour or are you just trying to get banned?