C Review
msb at sq.UUCP
msb at sq.UUCP
Sat Jan 17 04:42:37 AEST 1987
One more message that couldn't be mailed to "Peter Steele - Acadia"
(PLEASE get your software fixed!)...
All right, speaking as a professional C programmer, here are *my* opinions:
> "... 95% of all C programmers couldn't give you a good
> explanation of the term lvalue..."
True. And what's more, of the other 5%, they probably split
between two different explanations of what it means. Either
(a) something that you can put on the left side of "=", or
(b) an expression that designates a genuine object [including,
for instance, an array name, but not something like ++p].
> "... Switch/case could be classified as rarely used and should be
> kept till later."
Garbage.
> "... very few C programmers know much about sizeof..."
Not "very few", but "some". Your book can help educate them.
sizeof *should* be used in conjunction with malloc and fread,
for instance.
> "... 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, maybe 85%. I rarely use it myself; I think it's only useful
in connection with library packages where you want to conceal what
type something is, and in connection with portability definitions
such as size_t (the type of the result of sizeof).
> "... 99% of all professional C programmers have no idea
> what the comma operator is all about,
Garbage.
> 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..."
I tend to agree with this part, to a limited extent.
> "... Pointers to functions ... few C programmers understand
> them or would ever need them..."
Possibly true. It's certainly one of the more "advanced" parts
of the language.
> "... a C programmer never needs to know what a byte is..."
Well, it's what the value returned from sizeof is measured in.
A few comments of my own. I hope you guys are following the ANSI
people and their drafts of a C standard. It would be a good idea
to include in an appendix a summary of the innovations in the latest
draft, identifying it as a draft; for instance, the const modifier and
the signed char type.
If the book is really supposed to be introductory, I hope you will
include an appendix sketching briefly the things you didn't cover
(pointers to functions could well go there, I think, and maybe the
comma operator). I've seen one introductory C book that didn't
mention the existence of "short" and "long", thus guaranteeing that
their readers' programs won't be portable if their ints ever go over
32767... I think "long" should be introduced right alongside "int",
but it would have helped if they'd at least put it in an appendix.
Mark Brader, utzoo!sq!msb
#define MSB(type) (~(((unsigned type)-1)>>1))
More information about the Comp.lang.c
mailing list