[Cialug] Learning the 'C' language

[Tad Anhalt]

Nathan C. Smith wrote:
> Anybody know of a good place locally (DSM Metro) to learn 'C'?  
> Really just plain C, but maybe C++ if that's all there is.

   It looks like you've already received some valuable advice on how to 
start.  I'd like to add a few hard learned lessons that I wish I would 
have learned earlier.

   I'll limit my comments as specific to the C language as possible 
because much more scope could result in a book.

   Read the C FAQ:
	http://www.eskimo.com/~scs/C-faq/faq.html

   Do whatever it takes to learn what pointers are and how to use them. 
  Most C programmers haven't and it shows.

   Do whatever it takes to learn how to decode complicated declarations. 
  There are a few good tricks, Google knows.  K&R has a good section on 
it as well.

   Learn how the obfuscated and/or "efficient" and/or "mind blowing" 
code works, don't be tempted to use it in production code. Be aware that 
you will eventually see it in production code.  Probably late at night 
and in a debugger.  It'll probably be commented with something like 
"Don't change this code, you are incapable of understanding it."

   Find the warning level switch on your compiler and crank it up to 
"11."  If there is a switch that allows warnings to be treated as 
errors, it's useful to use it as well.

   Read the warnings produced.  This is where the "warnings as errors" 
switch comes in handy.

   Understand the warnings.  Fix them if possible, put a comment in the 
code for ones that you can't.  Figure out how to disable specific 
warnings for your compiler - best case on a line-to-line basis, next 
best on a per-compilation unit basis, worst case lower the warning level 
as a last resort.

   The idea is to keep the code in a state where there aren't pages upon 
pages of "expected" warnings streaming by that are hiding the ones you 
need to know about.  At the same time, you don't want to end up turning 
the warning level down to some useless level that doesn't tell you what 
you need to know.

   Find out if your compiler supports proprietary extensions.  Prefer to 
turn them off.  Especially if they conflict with something in the 
standard.  Even gcc supports non-portable extensions.  Some of them are 
useful and there is nothing wrong with them, just know that they are 
non-standard and you may need to know how to do without at some point. 
Don't let it be when a deadline is looming or support is unexpectedly 
removed.

   If your compiler supports multiple versions of the standard, set it 
to use the newest it knows about.  If it doesn't support the newest 
version, consider using a different one.  This isn't so much a problem 
for C, but C++ compilers have enormous differences in what they'll 
support at this point.

   Don't be afraid to break out a C++ compiler and let it see what it 
thinks of your pristine C code.  Consider making it a habit.

   If a function returns an error code, check it.  If you are making 
assumptions check them.  Be aware that most example code doesn't do 
either.

   Be especially wary of code you don't control and/or don't understand.

   Learn to use a debugger.  Learn to automate your debugger.  In fact, 
automate everything.  Start with the build process, continue with 
testing.  Finish up with...  Well, the job's never done, but every 
little bit will pay huge dividends later.

   You already know to use source control religiously, right?  Oops, I'm 
straying from C, better wrap it up.

   Whether you learn C from an instructor, book or end up having to 
strike out on your own...  Doing the above will help immensely.  At the 
minimum it will feed you an endless number of questions that you can ask 
the instructor (or even google) to explain the answers to.

HTH, Good luck.
Tad Anhalt