[Cialug] Learning the 'C' language

[Chris Hilton]

I'd just like to reiterate this:  Read the warnings and fix them first.  Use 
-Wall in gcc.  It will save you an hour at some point, and 6 hours some 
night!


On Wednesday 12 October 2005 11:17 pm, Tad Anhalt wrote:
> 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
>
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug

-- 
"The only winning move is not to play."