C Review

Israel Pinkas pinkas at mipos3.UUCP
Thu Jan 15 10:40:35 AEST 1987


In article <2313 at brl-adm.ARPA> Peter at adm.UUCP 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. Below is a list of some
>his statements. Is this guy for real? Your comments would be
>greatly appreciated. Incidentally, the text is not an intro
>text, it assumes the reader has finished a course in Pascal.

OK. Here goes...

>"... 95% of all C programmers couldn't give you a good
>explanation of the term lvalue..."

Wrong.  MOST C programmers that use the language extensively know that an
lvalue is anything that may be assigned to.  It might be true that many C
programmers don't know that it is called an lvalue.  But don't let that
stop you from teaching your readers that.

>"... Switch/case could be classified as rarely used and should be
>kept till later.

Wrong.  Besides being part of the language, case statement are usually a
much better form that 'if ... else if ... else' statements.  The code is
more readable (you can see the test being done because it is on the left
margin of the code).  Besides, you assume that your readers know PASCAL,
which has the CASE statement.  (Unless you assume that their PASCAL course
was wimpy.)

>"... very few C programmers know much about sizeof..."

If "we the programmers who call malloc" are a very small minority, I guess
that this might be true.  But reallistically, since any linked list, binary
tree, or dynamic array needs malloc, and since these are always good
excersizes (maybe not, but every course I ever heard of had them), you
would be wise to discuss sizeof.  At lease enough to do the above and be
comfortable.

>"... 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."

I would say closer to 50%, seeing as how many people are learning C on
micros and many of those compilers don't have typedef.  But since it has
been around since K&R wrote "The Bible", you just can't ignore it.  maybe
you should put it in one of the later chapters along with sizeof, malloc,
and the low-level I/O calls.

>"... 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..."

Wrong.  K&R introduce it relatively early.  Ans since it is nice to be able
to have 2 counters going in for loops (or 2 pointers, you get the idea), I
would introduce it.  Just after I introduce pointers.  Then I would write
all the versions of strcmp() that K&R do.  (Or some other function like
that.)

>"... Pointers to functions ... few C programmers understand
>them or would ever need them..."

I would say that most C programmers never need to use them.  But there are
some times that they are necessary.

>"... a C programmer never needs to know what a byte is..."

Unless he wants to do something useful.

It sounds like you got a turkey of a reviewer.  Either that, or (s)he
didn't know what (s)he were talking about.  Comments like the ones made
tend to indicate that the speaker had a C cource in college, and hasn't had
much use for the language since.  Since your readers already know how to
program a structured language, I would say that you might teach them what
you can do in C that can't be done in PASCAL.  (Besides strings, bitwise
operators, and such.)  The only thing that is not done easily in C is SETS,
but those can be simulated with enums or fields.

Good luck with your book.

-Israel

-- 
----------------------------------------------------------------------
UUCP:	{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas
ARPA:	pinkas%mipos3.intel.com at relay.cs.net
CSNET:	pinkas%mipos3.intel.com



More information about the Comp.lang.c mailing list