Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: C Review Message-ID: <5061@mimsy.UUCP> Date: Wed, 14-Jan-87 00:23:51 EST Article-I.D.: mimsy.5061 Posted: Wed Jan 14 00:23:51 1987 Date-Received: Wed, 14-Jan-87 06:10:26 EST References: <2313@brl-adm.ARPA> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 84 In article <2313@brl-adm.ARPA> Peter Steele - Acadia writes: [You did not include a return address, and the info-c -> comp.lang.c gateway consumed any useful approximations; hence the followup.] >This particular reviewer makes some statements that we find hard >to accept. ... Is this guy for real? I wonder. >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." That might well explain much of the code we have seen in comp.lang.c. :-) The term itself may be somewhat obscure, but the concept is very important in C (and many other languages). >"... Switch/case could be classified as rarely used and should be >kept till later. I count 80 occurrences of `switch' in one part of a 4.3BSD-beta kernel. The cases for these (excluding the code under them) make up another 374 lines. There are a total of 30829 lines in this section of code; that works out to about 1.5% of the source lines, including all comments. This is certainly rarer than, say, `if'. But there are only 177 `while's. Should these, too, be classified as `rarely used'? >"... very few C programmers know much about sizeof..." Again, that might explain.... One cannot even use malloc() without sizeof(). >"... 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." #defines can replace typedefs in many instances, but not all: typedef char name[5]; typedef name *(*pfnstring)(); pfnstring table[128] = { ... }; /* vs. char (*(*table[128])())[5] = { ... }; */ Using `typedef int (*pfn)()' has helped keep the sanity of many a programmer trying to create a table of function pointers. >"... 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." That might explain.... >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." It is true that one never needs a comma operator. It is also true that, given a subtract operator, one needs no add operator. Comma may not be as useful as add, but *any* serious C language tutorial should not neglect *any* operator. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." Perhaps few understand them, but they make a world of difference between C and Pascal. It is not possible to `send messages' to `objects' in Pascal; using function pointers, it *is* possible to do this in C. This is immensely useful. Using pointers to functions perhaps cut in half the size of a 68000 disassembler someone here was writing. The result is much clearer as well. A large number of Unix utilities use function pointers. Dynamic loading requires function pointers. Some specific uses may be esoteric. The concept is not. >"... a C programmer never needs to know what a byte is..." Probably true, given that few agree as to what a byte is anyway. Six bits? Eight? Nine? But a C programmer should know that these are common sizes for the `char' datatype, and that if a machine *has* a `byte' type, `char' is probably implemented using it. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu