Peter@adm.UUCP (01/14/87)
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. "... 95% of all C programmers couldn't give you a good explanation of the term lvalue..." "... Switch/case could be classified as rarely used and should be kept till later. "... very few C programmers know much about 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." "... 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..." "... Pointers to functions ... few C programmers understand them or would ever need them..." "... a C programmer never needs to know what a byte is..."
dlnash@ut-ngp.UUCP (Donald L. Nash) (01/15/87)
I tries mailing this to Mr. Steele, but the return address was just "Peter Steele - Acadia", no UUCP path or anything like that. So here is my stab at answering: In article <2335@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. 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. > > "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." > For the longest time, I didn't know what an lvalue was, but that was when I was still inexperienced with C. After becoming more knowledgeable about C I found out what an lvalue was and that is probably the case with other programmers as well. > "... Switch/case could be classified as rarely used and should be > kept till later. > I disagree with this. Switch is a valuable tool for making multiple decisions and should not be covered up. > "... very few C programmers know much about sizeof..." > I find this very difficult to believe, especially in UN!X environments where the system calls need to know the size of the objects they are operating on. > "... 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." > Then 99% of all professional C programmers are grossly underinformed and overworked. Again, I find this very difficult to believe. Typedefs make things like declarations and casts much easier as well as providing for information hiding (who cares what a FILE is as long as it works). I can't believe that any C programmer with any kind of experience would not know or care about typedefs. > "... 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..." > I'll admit that the comma operator may be one of C's less utilized operators, but not to the extent that 99% of the professional C programmers don't know or care about it. When you need it, you really need it and there is no substitute for it. As for it being obscure and unmaintainable, that is only the case if people are not taught how to use it properly. Besides, you said that this book is not an intro book, so that argument is invalid. > "... Pointers to functions ... few C programmers understand > them or would ever need them..." > The only thing hard to understand about a pointer to a function is how to declare it; int (*funct)() is a bit tricky, especially when you have arrays of them or functions returning them, but they also fall into the category of "if you need them, you really need them". Consider writing a general purpose sorting algorithm which sorts anything in any order. You simply give it a pointer to a compare function and a pointer to a swap function and a pointer to a function which knows how to step through an array or list of these objects and off you go. Try doing this seemingly simple task without using pointers to functions. > "... a C programmer never needs to know what a byte is..." If he is going to do system programming he better know what a byte is! Off hand, I would say that whoever wrote this review has a very low opinion of C programmers. He seems to think of them as novices who don't know or care about the power of the language they are using and he seems to want to keep it that way. Maybe he dislikes well written software. In any case, I would not take his comments too seriously. Just so you know, I have only known C for about a year and a half, so I am no wizard. But even at that, I am very comfortable using all of those constructs which this guy said most programmers don't know or care about. Hope this helps. Oh yeah, usual disclaimers about by employer apply. Don Nash UUCP: ...!{ihnp4, allegra, seismo!ut-sally}!ut-ngp!dlnash ARPA: dlnash@ngp.CC.UTEXAS.EDU BITNET: CCEU001@UTADNX, DLNASH@UTADNX UUU UUU U U The University of Texas at Austin U TTTTUTTTTTTTTT Computation Center U T U TT T U U TT "The world is basically non-linear." UUUUUUU TT TT TTTT
markg@amd.UUCP (Mark Gorlinsky) (01/15/87)
In article <> 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. > >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." Any C programmer, professional or not, who has compiled a program that contained the error "Illegal lvalue" knows that they tried to assign a value to an expression that should not assigned a value. The 'l' in lvalue means "left" and refers to the left side of an expression, such as a = 5. > >"... Switch/case could be classified as rarely used and should be >kept till later. Who is this guy kidding! Almost all the 'C' programs that I have written contained at least one Swith/case statement. Every 'C' program that has command line parameters should use the Switch/case statement to control the arguments from the command line. > >"... very few C programmers know much about sizeof..." For the home hacker this maybe true but, for the professional dealing with commercial code, not so. The sizeof operator is great for dynamically allocating arrays via calloc() and malloc(). The sizeof operator is also use to determine the storage size of integers on various machines and to aid in porting code from one machine type to another. > >"... 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." Typedef and #define are used inpart to add readability to the definition of variables. Typedef means just that, "Type definition", it does not mean that new types of variables are defined. Typedef provides more flexibility than does the #define when it comes to assigning names to "derived" data types. > >"... 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." The for statement is the most common place to use the comma operator. It allows the placing of multiple expressions in various parts of the for statement. You probably could live without it but, it is part of 'C' and sould be explained > >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." Leaving out any feature of the 'C' language in a book about 'C', would be like taking a bath without a bathtub. You would still have to find a bathtub to take the bath. Besides, what right does the publisher have to tell someone else what they sould and shouldn't know. > >"... Pointers to functions ... few C programmers understand >them or would ever need them..." This is true but, a good explanation of them and more would know and probably use them. Better to know it's there, than to have never known at all! > >"... a C programmer never needs to know what a byte is..." Is this guy trying to say that a 'C' programmer also doesn't need to know about integers, chars, doubles or floats. Try explaining that the value returned by sizeof, when used on an array of integers, is the number of chars contained within that array. Good Luck, and remember that only the size of char will remain constant from machine to machine. Though the views may be short and few, remember the transmission time isn't!
kimcm@olamb.UUCP (01/19/87)
> "... 95% of all C programmers couldn't give you a good > explanation of the term lvalue..." I don't think so, we're a software house with several *PROFESSIONAL* C programmers (both UNIX and *DOS C compilers) and nobody has any problems understanding lvalue and other abbreviations (technical compiler terms). But for an introduction to C it would be a good help to explain the meaning of such phrases. > "... Switch/case could be classified as rarely used and should be > kept till later. Switch/case - should be classified as a *VERY* potent language structure, and the usage and syntax should be laid quite clear for new C users, to avoid pitfalls especially the default fall-through mecanism, which is unique to C. > "... very few C programmers know much about sizeof..." I really doubd that this is true, experienced C programmers (pro's and non-pro's) will quickly find this routine instead of using a machine-dependent value of some datatype. Just consider the example: struct p { int p_num; char name[20]; char phone[12]; } person; while (read(fd,&person,sizeof(person)) == sizeof(person)) { ...do something to person structure... } and the usage without sizeof: struct p { int p_num; char name[20]; char phone[12]; } person; while (read(fd,&person,34) == 34) { ...do something to person structure... } And notice that the latter depends on integers being 16bit values, if you move to another computer where integers are 32bit values you'll have to edit and recompile your source - if using the former example you'll only need to recompile. But that's not it the code is easier understandable than the latter. > > "... 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." How much longer are we going to live with the myth saying that, professional programmers, are people with no in-depth knowledge of the tool they're using!!! You might as well say that *REAL* programmers work at the university and don't care about getting their hands dirty by programming for money (ie. become a profesional programmer) - BULL****! > > "... 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..." Might be a good idea to save the comma operator to late in the book, but it certainly should be mentioned, since most C programmers (-; at some point in their career will have to read other peoples C code and try to understand it. If the comma operator are left out - the person seeing in some code will be really puzzled by what's going on. (I've tried it myself, but I had a wizard to train me!) > > "... Pointers to functions ... few C programmers understand > them or would ever need them..." Ever tried to write programs that receives interrupts from user or external devices, if so you'll probably used signal(2) which returns a pointer to a function and takes a function as argument for action upon receival of the interrupt. Or to take another example try to sort a large array of structures, (actually pointers to structures) by a field in the structure. You can either write the sort-routine yourself or use qsort(3C) but this needs a pointer to a function to do the comparison between two elements of the array. OK, then you'll need only a brief understanding of what pointers to functions are - not the semantics of them -- BUT if you were to write the qsort routine you'd better know what pointers to functions are! > > "... a C programmer never needs to know what a byte is..." A C programmer never needs to know what ASCII is! A C programmer never needs to know what a computer is! A C programmer never needs to know who he is! A C programmer never needs to know! A C programmer never needs! A C programmer never know! ....when will all the biased viewpoints on what a *REAL* C programmer need to know and what he doesn't need to know stop ? Conclusion: I think all of the elements of the C language should be covered in a teaching book. Maybe not to make the new C programmer familliar with them all at once, but to make him/her able to understand other people's C code. And later on to use the book as a reference work. Kim Chr. Madsen
dave@murphy.UUCP (01/21/87)
Well, this one is bound to draw a lot of responses, so here's my $.02 worth: >"... 95% of all C programmers couldn't give you a good >explanation of the term lvalue..." If they can't, then somebody isn't doing their job. Lvalue isn't that difficult a concept to get hold of; it's just something that can have its value changed by one of the assignment operators: =, ++, --, and the <op>= type things. Most of the time it's not that hard to figure out: if x is a variable, then "x" is an lvalue (it's okay to say "x = 2"), but x+1 isn't (it's not okay to say "x+1 = 2"). >"... Switch/case could be classified as rarely used and should be >kept till later. Wrong. Which 3 out of 4 doctors did this guy get this from? >"... very few C programmers know much about sizeof..." This has not been my experience. Even if you're not doing systems work, you need to have a grasp of sizeof to do certain common things. For example, to allocate a space for something with malloc, you *must* have sizeof to tell malloc how big a space to allocate. (Unless you want to hard-code the size in, but if you do, I don't want to maintain your program.) I have an application which needs to treat structures of varying sizes in a type-independent manner; by judicious use of sizeof, I can change the elements in the structures without having to alter the code. Without sizeof, it would be a nightmare. >"... 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 tend to not use typedef quite as much as some people. Then again, I don't use the shift operators that often either, but that doesn't give me any right to scream that "no one wants it". >"... 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." The comma operator has its uses. There are a couple of common idioms: using it to increment two or more variables in lock-step in a for or while loop, and reading a line from a file and simultaneously checking for EOF in a while loop. Also, in the ANSI draft, the comma is defined as a sequence point which forces the thing on the left to be evaluated before the thing on the right, necessary for some types of numerical work, for proper handling of volatile things like device registers, and a million other uses. >"... Leave the comma operator altogether. An intro book is no >place for obscure and unmaintainable tricks..." This is personal flaming on the part of the author, not to be given the courtesy of a response. >"... Pointers to functions ... few C programmers understand >them or would ever need them..." Again, this may not be something that you need very often, but when you run into it in a program and run to your book and look it up and find it explained only as "something you don't need to know about", you're going to be very disappointed in the author. >"... a C programmer never needs to know what a byte is..." It's pretty hard to describe any concept of type sizes and storage units without knowing what a byte is. In fact, it's damned difficult to do any kind of programming at all without knowing what a byte is. In every "introduction to Fortran" course that I've ever seen, they start out by explaining about bytes and words. Not telling the student about bytes is like trying to explain English to an illiterate person and then telling them that they don't need to know what letters are. General comments: Please tell us the name of this reviewer, so that I can make sure to avoid his/her work. Words like "99%" and "never" indicate that the author is putting his personal predjudices ahead of his (or anyone else's observations), and that he is determined that what he says should be regarded as truth, despite his not having any facts, studies, or even reasonable subjective observations to back him up. Trying to pass off opinion as fact is a tactic commonly used by those who have no basis in logic to argue from. Furthermore: statements like "99% of all professional C programmers" are a psy- chological ploy; the idea is to convince you that the author is a professional programmer who is familiar with nearly everyone in the field, and that if you disagree with him, you must not be a professional programmer. (It's sort of like the arch-reactionary who tells you that "all decent and moral Americans" support his position, and that if you disagree, you must be a Communist and a traitor.) Phrases like "never need to know", and "couldn't care less and probably won't ever need it" indicate that the author believes that this information should be held back from students, presumably because the concepts are too far over their heads, so that they can be reserved for the "professional" programmers who are of course the only ones that can use them as God (and Dennis :-) intended. This strikes me as an example of the old "I know something that you don't know, and for your own good I'm not going to let you find out" mentatility; it's sort of like the sysadmin for a university machine who won't let students run the debugger because he doesn't want them "taking CPU time away from those of us who can put it to good use". It's terribly infantile, just a way to show superiority. As this usually is done to mask a perceived or real inferiority, I would wonder how much the author actually knows about the things he criticizes. If you know this guy, don't ever get into a political argument with him! Well, I'll get down from my soap box (or maybe it's a chad box) now. Sorry about the long-winded message, especially the last bit. It's just that it gets my goat when people like this go around presenting themselves as authorities in any field, but especially in computer science; computer types have a bad enough reputation with non-computer types as it is. P.S.: This is all assuming that the material quoted in the original article was a legitimate review; now that I think about, it sounds suspiciously like satire. If it is, I apologise. P.S.S.: This wouldn't happen to be John Dvorak, would it? --- "But I *like* cheap plastic keyboards!" -- Greg Hawkes Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL UUCP: ...!{sun,pur-ee,brl-bmd,bcopen}!gould!dcornutt or ...!{ucf-cs,allegra,codas}!novavax!houligan!dcornutt ARPA: dcornutt@gswd-vms.arpa (I'm not sure how well this works) "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
meissner@dg_rtp.UUCP (02/03/87)
In article <194@olamb.UUCP> kimcm@olamb.UUCP (Kim Chr. Madsen) writes: > > ... Just consider the example: > > struct p { > int p_num; > char name[20]; > char phone[12]; > } person; > > while (read(fd,&person,sizeof(person)) == sizeof(person)) { > ...do something to person structure... > } Let's indead consider this example. This is wrong, wrong, wrong (even though it may happen to work on your system). The second argument to read is a char *, not a structure pointer. To pass lint (and to have it work on word-based machines), it should read: /* ... */ while (read(fd, (char *) &person,sizeof(person)) == sizeof(person)) { /* ...do something to person structure... */ } -- Michael Meissner, Data General ...mcnc!rti-sel!dg_rtp!meissner
kimcm@olamb.UUCP (02/12/87)
In article <954@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes: ] In article <194@olamb.UUCP> kimcm@olamb.UUCP (Kim Chr. Madsen) writes: ] ] [Some code of mine...] ] ] Let's indead consider this example. This is wrong, wrong, wrong (even ] though it may happen to work on your system). The second argument to ] read is a char *, not a structure pointer. To pass lint (and to have ] it work on word-based machines), it should read: ] ] /* ... */ ] ] while (read(fd, (char *) &person,sizeof(person)) == sizeof(person)) { ] /* ...do something to person structure... */ ] } Well, I made a mistake, I wrote the code on the spot and forgot to cast the struct pointer to a char pointer. Yes I know they have different types, but that doesn't make the example (of proving sizeof as essential knowledge to a C programmer) invalid. Kindly Regards Kim Chr. Madsen
wozniak@utkux1.utk.edu (Bryon Lape) (10/24/89)
I have 2 questions concerning function definitions: How does one write a function so that some, not all, or the items passed can be any type of variable at any time? How does one write a function so that any number of variables can be sent? Any example of the first question is a generic swap(). I know that pointers to void type are used in some way, but I do not know how. An example of the second is the printf() where the passed string will determine the other passed variables. This one is most likely taken care of at compile time, but I am talking run time. -bryon-
hascall@atanasoff.cs.iastate.edu (John Hascall) (10/25/89)
In article <1248@utkcs2.cs.utk.edu> wozniak@utkux1.utk.edu (Bryon Lape) writes: } I have 2 questions concerning function definitions: How does }one write a function so that some, not all, or the items passed can be }any type of variable at any time? How does one write a function so that }any number of variables can be sent? Use Ada? :-) Use varargs. } Any example of the first question is a generic swap(). I know }that pointers to void type are used in some way, but I do not know how. }An example of the second is the printf() where the passed string will }determine the other passed variables. This one is most likely taken }care of at compile time, but I am talking run time. Printf's control string is generally evaluated at run time. I suppose you could use that or similar techniques, i.e.: void swap(void *x, void *y, size_t bytes) { tmp = malloc(bytes); /* just a program sketch.... no flames */ memcpy(tmp,x, bytes); /* on it's lack of completeness PLEASE */ memcpy(x, y, bytes); memcpy(y, tmp, bytes); free(tmp); } swap(&foo1, &foo2, sizeof(struct foo)); John Hascall
readdm@walt.cc.utexas.edu (David M. Read) (10/25/89)
In article <1248@utkcs2.cs.utk.edu> wozniak@utkux1.utk.edu (Bryon Lape) writes: > > I have 2 questions concerning function definitions: How does >one write a function so that some, not all, or the items passed can be >any type of variable at any time? How does one write a function so that >any number of variables can be sent? > The best way I know of to handle both problems is with a variable argument list, which is covered under ANSI C. It works like this: #include <stdarg.h> func_1 (int parm1, int parm2, ...) { va_list arg_list; int junk; va_start (parmN, va_list); junk = va_arg (va_list, int); va_end (va_list); } Clearly, any type of variable can be passed, but you need to know several things to use va_arg: 1) The type of the next variable on the list 2) How many variables there are in total. Both of these can be determined from a format string passed to the function (as in printf()). In the above code, parmN refers to the LAST of the known parameters in the declaration (you must have at least one which is known). The parameters parm1, parm2, ... , parmN may be of any type. Call va_arg once for each variable in the list, with the correct type. Be sure to call va_end when you're done or you get funny gremlins later on. I have been doing a bunch of variable argument-list processing recently, so I can show you actual working source code if you like. ---------------------------------------------------------------------------- David M. Read best -=> readdm@walt.cc.utexas.edu all-else-fails -=> read@physics.utexas.edu "...[he's] stupid and he's ignorant but he's got guts...and guts is enough!" ----------------------------------------------------------------------------