C Review

[Henri J. Socha socha]

>"... 95% of all C programmers couldn't give you a good
>explanation of the term lvalue..."
How true. Now, before you disagree, ask programmers who do not read comp.lang.c
(or similar).  To them C is a tool, just another language to write a programme
in.

>"... Switch/case could be classified as rarely used and should be
>kept till later.
>"... very few C programmers know much about sizeof..."
Well, I must disagree with this.

>"... 99%  of  all  professional C  programmers  have no idea
>what typedef is all about, couldn't care less and probably
>won't ever need it."
There are those who cut their C teeth on small machine with OLD compilers (read
not full K&R) that did not have typedef!  There is lots of code here with:
	#define ATYPE struct astruct
	ATYPE { ... /* field definitions */ };
	ATYPE aVariable, *pointToStruct;
Notice how typedef has been worked around.  (Not couldn't care less but,
wouldn't do better or didn't know better.)
As for "Won't ever need it",  anytime they (you) use a struct you should
use a typedef.  My Pascal (AlgolW, WATFIV-S) background is showing.
Define your constants, then your types, then your globals, etc.
(You should be putting all new programmes in full ANSI C compatibility mode.
it can only help in making sure everything is right.  How many times did that
bug turn out to be a wrong function declaration or passed paramter?????)

>"... 99%  of  all  professional C  programmers  have no idea
>what the comma operator is all about, couldn't care less and
>probably won't ever need it."
>"... Leave the comma operator altogether. An intro book is no
>place for obscure and unmaintainable tricks..."
This is one obfuscation that I wish did not exist with one exception (inside
"for" expressions).  Those who use "if (bool) expr, expr, expr;" deserve bugs.

>"... Pointers to functions ... few C programmers understand
>them or would ever need them..."
Sad that they do not understand another of C's great features.  Be sure to
push this one in the book.  Many assembly language programmers know and 
use this.   Any time you have a table containing numbers (in one field) that
is then used to switch with, you could have had a table of pointers to
functions and eliminated the switch/driver overhead.
I know of an I/O subsystem that for its "file pointer" used a pointer
to a structure of function pointers.  It was easily extensible, logical,
and the FASTEST I/O package on the machine.  Part of its speed was that
when you wanted to write/read/etc. you directly called the disk/printer/display
I/O routine desired without having to go through some file pointer -> device
driver -> I/O routine overhead.   It was Object Oriented!

>"... a C programmer never needs to know what a byte is..."
Portable software requires such but "need" is the incorrect word.
Just listen to the bigendian .vs. littleendian debates in comp.sys.arch(?).

Finally, good luck on the book and be sure to use it as a vehicle to
educate GOOD programming techniques as well as learning to programme.

-- 
UUCP:...!amdahl!drivax!socha                                      WAT Iron'75
"Everything should be made as simple as possible but not simpler."  A. Einstein