C Review

[Brian Case]

Oooooo, I like queries such as this.  Since I am a "professional C
programmer" (currently writing compilers, mainly), I have definite
opinions on the comments from this guy.

In article <2313 at brl-adm.ARPA> Peter Steele - Acadia writes:
>I am currently finishing up a new text book on C with a colleague
>of mine and we just received the last of several technical reviews.
>This particular reviewer makes some statements that we find hard
>to accept. However, we're just two people, so we decided to get
>some opinions from other C programmers.
>
>"... 95% of all C programmers couldn't give you a good
>explanation of the term lvalue..."
Well, what is a "good explanation."  I think I disagree with this
though (how about "something that can be dereferenced"?  I just looked
it up in Aho, Sethi, and Ullman's new dragon book:  "... r-values are
what we usually think of as 'values,' while l-values are locations."
Do I pass?).

>"... Switch/case could be classified as rarely used and should be
>kept till later.
Now wait a minute.  This is clearly BS.  Where would I be without
switch and default?  Like, nowhere, man.

>"... very few C programmers know much about sizeof..."
What is "much about"?  I think this is BS as well.  This ties in
with the "... a C programmer never needs to know what a byte is...."

>"... 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."
Well, I disagree with "have no idea what typedef is all about," but I
may agree mildly that they won't use it much.  I never use it, but I
am very lazy.  Frankly, I very rarely see it, and I see a lot of code.
But this is no excuse for leaving it out, *especially* if the audience
of your book is expected to be PASCAL graduates (they will ask "where
are the TYPE statements?").  Besides, being at least exposed to the
full language is important.  Maybe you shouldn't use it in ALL of the
example programs, but....

>"... 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."
Wow, this guy can make lots of strong statements.  I have used it, but
I try to avoid using it since I find it confusing.  I think the "advantage"
of having all the initialization (for example) within the parens of the
"for" statement is not worth the grunginess of the syntax.  Besides,
with modern compilers, who knows in what order things will be done.

>"... Leave the comma operator altogether. An intro book is no
>place for obscure and unmaintainable tricks..."
It is part of C.  If I used your book, and then later found out about
the comma operator, my reaction would be "gee, what a worthless book,
it doesn't even document the entire language!"  What if the student
encounters code with the comma operator?  He'll be *forced* to go to
a "better" book!  You don't have to devote 10 chapters to it....

>"... Pointers to functions ... few C programmers understand
>them or would ever need them..."
While I don't use them much (maybe ever?), the ability to develop a
pointer to a function (and arrays of, and ...) is so powerful that I
often ask myself "wonder if I could pass a pointer to a function here."

>"... a C programmer never needs to know what a byte is..."
Sigh, I wish this were true.  And even if it were true, it wouldn't
prevent students from *finding out* about the relationship between bytes
and words and pointers and structures and etc.  I don't know what you
said in you book to provoke this comment, but it is probably worth
mentioning to C programmers as early as possible that it is quite
within the limits of C to write machine-dependent code.  At least
warning them that they may encounter code which assumes things about
"byte" and "word" equalling "char" and "int" respectively is probably
in order.

    bcase