Date: Wed, 20 Jul 1994 14:19:27 -0700 Subject: FYI: Review of C/C++ books From: Scott McMahan <-- before 8/95 From: Scott McMahan <-- after 8/95 The Cyber Reviews presents: The C and C++ Review (version Prerelease-A) Entire Contents Copyright 1994 Scott McMahan Copyright 1994 Scott McMahan This work is not public domain. If it were, some not-very-nice person would probably publish it and make a lot of money from it. If anyone is going to make money from it, it should be me, since I wrote it. I don't think it would make much money. I don't particularly want any money to be made from this -- it is a freely available document after all -- but I also don't want other people publishing my writing without me even knowing about it, much less getting paid for it. Respect the copyright! I poured a lot of work into this, for no other reason than the fact I wanted to and that it would be useful. You should respect that and not violate the copyright by publishing this without my consent or knowledge and making money off of it. I encourage you to print this out for your own use, or to share with classes and co-workers, but not to make money off of it. Trademarks are not specially designated, since this review is about books and products and every other word would have to have a after it. Trademarks belong to the individual trademark holders, and context is sufficient to let you know what is a trademark and what isn't. Contents: Introduction Books Not Included About the Books C and C++ Criteria For Inclusion Judgment Calls and the Editorial License Availability of Books Protecting Your Investment FAQ Start Your C Notebook Quickie Learning C Teach Yourself C Teach Yourself C++ The Waite Group's New C Primer Plus, 2nd Edition The Waite Group's C++ Primer Plus teach yourself...C teach yourself...C++ Fin Intermediate C K&R (The C Programming Language) The C Programming Language 2nd Edition The Development of the C Language C: The Complete Reference C++: The Complete Reference C and C++: The Pocket Reference Practical C Effective C++ Programming C Elements of Style C++ Programming Style Writing Solid Code Code Complete Fin Advanced C Advanced C Advanced C Programming Data Structures And Algorithm Analysis In C Fin Other C Books Expert C Programming: Deep C Secrets Turbo C/C++: The Complete Reference The Art of C Born To Code In C The Annotated ANSI C Standard A C User's Guide To ANSI C Power Programming... Turbo C++ Advanced Programming In The UNIX Environment lex & yacc The End Introduction A frequently asked question is: "What book should I read to learn C?" This question appears in many different wordings just about every day on Usenet's C discussion newsgroup, comp.lang.c, and in many other places besides. On Usenet it is usually followed by a one-line reply or three randomly naming books. Occasionally, there's an in-depth review of a book or two. But these reviews do not seem to be saved. They aren't easy to get. There's a frequently asked questions list, but it does not cover this topic in considerable depth. It names a few books that are considered the "best", which I have not seen on any local shelves, without reviewing the pros and cons of all available books. The C++ FAQ copy I have doesn't even have a section on books. The purpose of this review is to create a source for information about what C resources are out there. I have tried to describe in fair detail all the C books possible, reviewing the contents of the book, whether it lives up to its own billing or not, the best audience for the book, and so forth. And, I've been fairly detailed about what books have in them, in case you're looking for a specific thing like a ready-to-type-in random number generator. I've also included enough information to allow people to order the books. The books are in no particular order within the broad categories. I hope the review can be used either as a way to look up individual books, or as a cover-to-cover read for a survey of what's out there. This review is not exhaustive, but it is as close as I've been able to come. It will at least give you a starting point to form some ideas about these books. From here, you can chart a course towards where ever you need to go. The intended audience of the review is: People who want to learn C (either as rank beginners or as C programmers who want to get better) and don't know what books to get. I suspect this will be the major audience component, since the question is asked so much. People who need an annotated bibliography of C books, either for students to read, to decide which book to use or recommend, or whatever. It is a general purpose list of books. Hopefully the writing is approachable and friendly without getting too dry and boring. In the review, we'll meet such surprising things as ichthyology in real life, bison, insane discreet mathematicians, Peter Norton, and of course a cow. Not your everyday boring computer stuff. But, then again, the books are for the most part very technical or incredibly technical, and you have to know what you're doing to get the most out of the review. There are four sections: Books for beginners who know nothing about C but want to learn. Intermediate books for people who know C but want to know more. Advanced books for people who need to advance further. An others section that includes books not in the other two. This text is available as an attractive PostScript document, which I created in Ami Pro 3.01 under Windows 3.1. It can be printed on a laser printer and looks very professional. The review is also available as an ASCII text for people who either can't, or don't want to, print out a PostScript file. Obviously, the PostScript version looks a whole lot neater and is something you can impress your friends with. It is a booklet format document you can use to start your C notebook of interesting and important articles with. If you have a choice, you should print out the PostScript version. On the other hand, the ASCII version has the exact same text as the PostScript, so you're not missing anything but aesthetics. All the information is still there. Who am I to tell you what books to read? I'm a pathological basket case who actually enjoys reading books about C, and about just about any other computer topic you could name. I've always loved reading computer books, and always liked C. I taught myself how to program in C using some of the books listed here, and am competent enough to be able to evaluate the books. This is a free (but copyrighted) work -- what do I get out of it? First, of course, I got a lot of books. I also got a very nice example of desktop publishing to serve as a sample of what I can do. That's always beneficial. And of course I get a warm, glowing feeling I've made the world a better place through the review. Seriously, it does distress me how often questions about books are asked. Caveat: C is a religious programming language, which means a lot of people will have very strong views about it. This review reflects the opinion of one reasonably well informed person. Some people may disagree with what I've written. You may even disagree with me. But, this is a review to get you thinking. It is a review, and that implies opinions. But C is also more than just a means to an end. People enjoy coding in C. They like it. The language has sublime elegance and beauty. If you become a C programmer, you're more than just another coder, you can write code that you are proud of. The opinions are part of that. There is the one true holy style of indenting and other religious issues, and people debate and argue because they love the language so much. C has an obfuscated C code contest, because it is about the only language in which such a thing is possible. C lets you do anything you want. But that implies great responsibility on the part of the programmer to manage that responsibility wisely. And there are preachers and evangelists who will help tell you the right way to do it. They want to show you the light. Some of whom, by the way, who have written books. The Cyber Reviews has been known to-date as a review column for comics. It started out, very much accidentally, by gradually reviewing more and more comics. It got to be such a big deal that I thought I might as well review books, too. I need some kind of outlet for my reviews, and this is the best one I can find. Especially since I found a topic on which a review is badly needed. This C Review is planned as the first in a series of two volumes. The second will explore other general computer books. After that, who knows? Are you going to use this review? If you read this, and find the information herein has helped you; or if you are going to show this to your class, your company, your local C therapy group; or hang it up and throw darts at it -- drop me some e-mail and let me know. I'm interested in whether this is actually useful or not. I can be reached at the e-mail address mcmahan@cs.unca.edu If you have any sort of opinion at all about what I've written, don't hesitate to send it to me. Special thanks! This review was only possible because of the help of the companies which participated! Without the cooperation of review copies, this would never have happened. It would not be physically possible to actually buy all these books, especially not for a college student turned graduated but unemployed job seeker. I stopped counting when the cover prices of all the books got above $400. (I don't mention price much in this review, mainly because prices are prone to change rapidly. What I write may not be the case in a year or two. And, a lot of computer books are sold at a discount -- the cover price is like the sticker price of a car, subject to negotiation.) The Cyber Reviews is indebted to these companies for their assistance, since this review would be a lot slimmer without their participation. O'Reilley & Associates Microsoft Press MIS:Press Addison-Wesley Prentice Hall Special thanks to the following people: Tiffany Moore at Addison-Wesley's professional division, and her counterpart Barbara Warren in the educational end; also to Beth Hespe at Prentice Hall; Brian author Herbert Schildt; author . All these people did something or the other that made this review possible. Or at least increased my credibility by dropping their names. If you or your company publishes a book about C or C++, and it isn't reviewed here, you need to let me know about your book ASAP. People will read this review, which will probably be come the standard Internet bibliography on C and C++ references (just because it is the only one -- unless it is superseded by something else better), and not even know your book exists, and think they need to choose between one of these. You'll be at a disadvantage. Send some e-mail to me at the address mcmahan@cs.unca.edu for more details on how your book can be here. Do not be intimidated -- the books all get a fair reading, and are judged on their merits. I make it a point to approach every book with no preconceived notions. If you publish a great book, I'll tell it like it is. If you publish drivel, I'll make people aware of that too. It's all up to you and what you publish. Do you want to publish this review? It might be good as a handbook. A published version would reach more people than an electronic one. If you are interested in publishing it, send me e-mail. Books Not Included This section gets smaller and smaller as more and more books pour in. Books on Microsoft C/C++, Visual C, Quick C, etc. are not included simply because I have not ever not even once used any MS C compilers, have absolutely no books about them, and don't have any way to get them. The only PC compiler I have ever used is Borland C++ 3.1. Windows programming books: I don't have that many, and if I got that many I'd do a Windows Review. If you want to see that, send me Windows books. And a copy of Visual C++...About the Books C and C++ Originally, this review was going to be a C review with some C++ books included. Namely the complementary books such as Teach Yourself C/Teach Yourself C++. But, as time progressed, it eventually became a C and C++ review. There were getting to be as many dedicated C++ books as C ones. So I decided to change the name of the review to C and C++. C++ has proven itself to be the de facto successor to C. You almost can't get a plain C compiler anymore. All the main DOS and Windows based compilers are "C/C++", and the GNU compiler is a combined C and C++ compiler. Except for a couple of very rare and mostly unimportant cases, C programs are C++ programs. C++ has proven to be versatile, allowing both serious object oriented programming (OOP) use and "just a better C" (with stronger type checking and VAR parameters) use. The fact that major compiler writers have pushed C++ has certainly helped it achieve popularity. It is also important for the student to learn C++. Knowing C isn't sufficient anymore, as more and more of the world moves to C++. And more importantly moves to object orientation. Everything is becoming object oriented from operating systems to APIs to networking. If you have to be object oriented, doing it in a C language derivative is the best way. For a C programmer. C++ is an object oriented language grafted on top of C, though, and if you do not learn C you are going to be in really bad shape. C itself is a serious language with a great deal of subtleties, and takes time to master. It has a lot of fundamental differences between itself and other procedural language like Pascal and its derivatives: stream I/O, pointers, hardware closeness, library functions, etc. C++ is a language that inherits all of C's quirks, adds on object orientation, and has its own quirks and syntax. All this is too much to tackle at once. Also, there is plenty of C code still around, and knowing C is essential for any modern programmer. C is not going away in any of our lifetimes. Criteria For Inclusion As it has been said of other things, if you took every C and C++ book and laid them out end to end, you'd have engaged yourself in a monumental waste of time. But there are a lot of books on C and C++. It seems to me like every company has 3-10 general books on C and C++ (learning C, really learning C, and stuff you haven't learned yet about C), and a lot more specific ones (writing device drivers on binary programmable load lifters in C for embedded 68000 processors). Books are chosen for inclusion on only one criterion: I've read them! Whether it was through convincing a company to send me a copy to review, having my own copy to begin with, getting a copy for a course, finding a copy in the library, or stumbling over a copy via someone I knew was trying to get rid of, I somehow came into the possession of the book. Thus, some really great books are included, and some losers. I think the bad should be detailed along with the good, just so you won't be tempted to buy them. Judgment Calls and the Editorial License Books are reviewed on their own merits. If a book is good, I'll praise it. If a book is bad, I'll damn it. The success or failure of a book is entirely up to the author. I just call it like I see it. Some books in this review get pans, and I firmly believe it is because the books are harmful to C or C++ programmers. If books encourage bad style, I call them on it. I also flag any type of discrepancies between a book's billing and what it delivers. Some books try to convince you they're ANSI C compliant, and they really are not. On the other hand, if a book does a good job at something, I'll point it out. I employed an editorial license on a couple of books only marginally related to C. You can try to decide which ones as you read the review. Availability of Books Availability of these books is on a BSL basis -- blind, staggering luck. Your local store might have them. It might not. Who knows? Not me, that's for sure, and I want to insert a disclaimer to that effect. All I know is that, locally where I live in Asheville, NC, there are three chains: Books-A-Million, which has the largest selection of computer books and has books from just about all publishers, including being the only store that has the Microsoft Press books; B. Daltons, which has a few of the Osborne/McGraw-Hill books; and Waldenbooks, which doesn't have much of anything. Your mileage may vary. At best, you'll go into the closest chain store, and find the book listed in this review that you want to get, and it'll be half off -- and the salespeople will be friendly and helpful. Yeah, right. Bring me back a lollipop from Fairy Land. Most of the time, you'll go to two or three stores, the last one will have it, and you'll get rude and ignorant salespeople. But, at least you'll have the book. That's how they stay in business. At worst, you can't find a book you see here. You can almost certainly order it if you have a chain store in your town. All you really need to order a book is the ISBN, the International Standard Book Number. Given that, just about any Waldenbooks or B. Daltons can order any of the books in this review. I recommend writing the ISBN down on a piece of paper and handing it to the person, rather than read it off to the usually-clueless shmoe behind the counter. The ISBN (allegedly) uniquely identifies a book. You don't even need the name of it or the author. Which is probably good, because the simpler you can make the ordering process, the better your chances of success finding the book. An anecdote vis-a-vis ordering books is C: The Complete Reference. I needed a complete reference on C for my first job, and there was not a single copy in town. I had to order it, and wait a week to get it, all the while using less-than-great man pages as a reference. Within a month of getting it, B. Daltons had a shelf full of them! Many book publishers hang out on CompuServe and other online services, if you're really desperate. They sometimes run specials and discounts there. It's worth checking out if you're a subscriber to one of those services. If you order enough, they sometimes give you credits to help pay for the pay-per-byte expensive information services. Also, a lot of publishers have mail-order services. Check first, before sending cash, because some don't. To facilitate ordering books, I've provided every entry with a line like: Everything You Wanted To Know About C But Were Afraid To Ask by The Author published by Fli-binite Pulp Press ISBN: 187-WITH-MY-GLOVE-IN-YOUR-MOUTH The best place to find expensive computer books is in the library. Go there first, especially if you just want to look something up and don't want a copy to keep. The other best place to buy computer books is on sale. Wait till after Christmas and hit the sale racks. Also, if a book liquidation hits town, be sure to haunt it. I got the following books: PC Intern ($60), Windows 3.1 Intern ($50), OOP In C++ ($30), Learning C++ ($30), Power Programming...Turbo C++ ($30) and X Windows System Programming ($30) for under $20 (about $250 cover!). These are all very relevant, more-or-less up-to-date, useful books. Sure, there were 10,000,000,000 books from the past three releases of most popular PC software applications and Windows 3.0 and so forth, but there's also some gems. You have to be the archaeologist and do a little work to find the books. Paying full-price for a computer book should be a last resort. The cover price is like the price of a used car -- it should be subject to negotiation. Book stores know that the books are too expensive, and know that they'll have to put them on sale to get people to buy them. Protecting Your Investment Given the rapid turnover in computer books, and how expensive they are, you may be considering how to protect your investment. You see thousands of dBASE III, Paradox 3.5, Ami Pro 2.0, and Excel 3 books piled up to the ceiling on sale, and know for every copy they didn't sell, 5 or 10 were probably sold. Will the $100 book you buy today be useful 5 years from now? 2 years from now? In most cases -- like application programs -- the answer is a resounding, absolute no. But, for the books we're looking at here, the answer is a resounding "maybe". And, for computer books, that's as close to written in stone as you'll ever get. C books are very stable. For the most part. Anything based on the ANSI C standard is not out of date, and is not likely to become out of date in the near future. You can buy them with security and assurance you'll wear them out before the information changes. Most books now have been updated to cover the ANSI standard (indeed you'll see a lot of 2nd editions in this review that were updated just for that reason). There is talk of somehow updating the ANSI standard, but even if it is updated, there is likely to be no significant change to existing C that would make any books invalid. Of course, this means the odds of finding a close-out, liquidated, or on sale C book is slim (but not impossible -- look at the liquidation list above of what I got). If it isn't going to be replaced, they won't try to unload old ones. But, an important warning is: books about a specific version of a specific compiler such as Borland C++ 3.1 or Microsoft C 7.0 are likely to become quickly out of date, as the new versions of a compiler augment the old with lots of features -- and sometimes change the way the older version does things. If you want a book for a specific compiler, it is very important to get one that covers the version you have. Otherwise, it may not be of any use to you. Compilers have been known to change radically between releases. C++ is very different than C. It has no standard. (Yet: one is being worked on.) Like K&R being the de facto standard for C before the ANSI standardization happened, the AT&T version of C++ is the de facto standard for C++ until an ANSI C++ committee can come up with a real, carved in stone standard. AT&T C++ has different version numbers. AT&T C++ 1.0 is totally out of date. AT&T C++ 2.something is what most compilers on the market implement. It is also what most (but not all) books in this review will teach you about. AT&T C++ 3.something is the newest version, which includes exception handling and templates. Change is very possible in the protozoic C++ evolution. As you read some 2.something-based books, you'll see some examples (one of which is the streams changed utterly between 1.something and 2.something). Now, most features of C++ are fairly finalized. If you learn C++ version 2.something, it is safe to say that most everything you learn will remain true for the near future. New things may be added on, however, and you'll have to learn them. FAQ The newsgroups comp.lang.c and comp.lang.c++ both have Frequently Asked Questions lists. The C++ one is even available in Windows' help file format (.HLP). These are invaluable resources for getting your questions answered. You really, really need to have these both printed and online for your reference. All FAQs can be gotten from the FTP site rtfm.mit.edu. The ASCII version of the C++ FAQ should tell where the .HLP version can be found. Start Your C Notebook A C programmer needs to have a C notebook. Get a fairly large one and add important stuff you find to it. Start with this review. Then print out the paper on the Development Of The C Language described below (in the Intermediate section after K&R). Next, add the FAQs described immediately above to it. Add important articles from magazines and Usenet, baffling examples of C code, and other worthwhile information as you run across it. My C notebook has a copy of a draft of this review (I had to print it out for proofreading & editing, and to check the layout of the artwork and stuff), the Development paper, a xerox of K&R's original edition (now out of print, of course, but my library had it), and the chapter from Teach Yourself DOS on how to write batch files. I'm not entirely sure why that last item is in there. Quickie If you're a hectic, frantic, fast-paced Type A who doesn't want to read all this, a good starting bookshelf for a C programmer is: Teach Yourself C K&R C: The Complete Reference C Elements of Style C++ Primer Plus Learning C The books in this chapter are not mutually exclusive. Reading one C book is like looking at one side of a sculpture. You don't get the whole picture. Each author has a particular way to approach the subject, and a particular slant. Others may approach topics from a different angle, one that helps you understand the topic better. Since you're a beginner and don't know what the criteria for C books are you should be looking for, I make some recommendations. If for some reason choose to follow these, and become a deranged serial killer, it isn't my fault. Teach Yourself C by Herbert Schildt published by Osborne/McGraw-Hill ISBN: 0-07-881596-7 WARNING! If you intend to buy this book, make sure you are getting the real thing. There is another book called Teach Yourself...C -- the only difference is the ellipsis in the title. The correct book Teach Yourself C is blue with stripes. The impostor is bright yellow. This warning is included because in my experience stores tend to have the impostor and not the real thing. Teach Yourself C is a highly recommended book for people who have never programmed in C before. It is a well written gentle introduction to C. In my opinion, it is the best book available for absolute beginners who have not ever done any C programming. I personally learned C using this book, and although I've read a lot of other books since then, I've yet to find one better. The book employs the Mastery Learning Theory, which means that it takes each topic and breaks it down into little chunks that are easy to understand. Each little part is made up of an explanation, some examples, and excercises. There are other exercises that help you integrate the parts into a whole. C really lends itself to this treatment. Here is an example: the File I/O chapter is broken down into: an explanation of streams; basics such as fopen() and fclose(), and fgetc() and fputc(); an explanation of feof() and ferror(); fputs() and fgets(), then fread() and fwrite(); an explanation of random access and fseek() and ftell(); and so forth. Each of these sections is laid out in the explanation/examples/excercises format. The book covers: fundamental syntax, decision control statements, looping control statements, data types, arrays and strings, pointers, functions, I/O, structures and unions, advanced stuff, and the preprocessor. (There is an appendix telling about library functions.) The overwhelming amount of examples is this book's strength. Even the exercises have complete answers, which means there are even more examples. Teach Yourself C is somewhat DOS slanted. Schildt uses a few DOS-specific functions like getche() and kbhit(). He does explain that they are non-standard DOS functions, though. The book is mostly ANSI generic and is applicable to any ANSI C compiler. As you'll notice, most of Schildt's books are based on DOS. If you're learning on a UNIX machine, you may find the few DOS remnants a little disturbing (since there is no kbhit() etc.), but these really are minor and don't matter much to this book. 99% of it is generic ANSI C. In terms of C idioms, Schildt does teach some to you. He doesn't overdo it with obfuscated code, but he also doesn't protect you from real C by infusing his book with baby talk either. Here's an example: "Although not incorrect, you will almost never see a statement like num = num + 1 in professionally written C programs because C provides a special operator that increments a variable by one. [... you can rewrite:] i = i + 1; into i++;" Obviously, Schildt assumes you want to learn real C. I personally think this is good, since it teaches you the "right" way to do it from the outset. Presumeably C programmers will go on to read C-infested literature (like Dr. Dobbs or Byte) and other books, and it is good to teach the most widespread idioms of the language. (This suggests a tangent: It never ceases to amaze me that people pay good money for books like C For Complete Idiots, which insult their intelligence. If I had $30 to spend on something, I wouldn't do it in a way that lessened my worth as a human being. Apparently, though, these books are very successful. You, my readers, are worthless, inconsequential motes in a universe filled with vast intelligence you can't even comprehend! Don't you feel stupid? Must I continue?) Note: This book does not go as far as some of the others in this review. It more or less teaches the language, and stops. That's because of Osborne's categorization system. There's a book that follows this one, called Advanced C, which goes into more of the things you can do with C once you learn it such as creating data structures. The books are designed as a series and don't step on each others' territories. Anyway, it's a good introduction to the language. Teach Yourself C++ by Herbert Schildt published by Osborne/McGraw-Hill ISBN: 0-07-881760-9 There are two approaches to learning C++. One mandates learning C first, because C++ is like C only more so, and unless you are an accomplished C programmer who can make C jump through hoops for you, you're going to be totally messed up trying to tackle one of the most complex languages ever conceived. Namely C++. The other approach says that you're better off just learning C++, because the more C you know the more you'll have to forget to be able to use Object Oriented Programming (always referred to as simply OOP) to your advantage -- or you'll be a programmer who uses C++ as a new and improved C with reference parameters and miss out on the good things that OOP can do for your life. Teach Yourself C++ takes the first approach. We'll meet a book later that takes the second. Schildt writes: "Put simply, you can't learn to program in C++ until you can program in C." If I had to choose sides, I would agree with him. I don't think trying to learn a language as idiosyncratic as C++ without being well versed in just the sheer philosophical point of view that C has is a good idea. Especially if you're learning C++ for the object oriented features -- you'd probably have to have therapy if you're coming to C++ from a real OOP language like OOP LISP or something. The shock would be too much for your mind to take in. Unless you're already comfortable with side effect operators, ternary ?: operators, pointers, streams, and other very C-ish ideas, you'll be in trouble. (Luckily I don't have to choose sides, I can read books that promulgate both philosophies regardless of the effect it has on me. Of course, I'm also a basket case.) Schildt's introduction to C++ is based on the same Mastery Learning Theory as his book Teach Yourself C (q.v. above). C++ lends itself to this format, because that's what Object Oriented Programming is, taking big things and making lots of little self-contained things out of them. The book is good for self-learning because of the good organization. This book emphasizes OOP. Before any C++ code is written, the Three Holy Principles of OOP are explained, and the book teaches C++ as an object oriented language. As the book covers C++, it explains how the features are used to implement OOP techniques. The book's starting to show its age a little. Everything in it is still valid C++, nothing has been radically changed, but it lacks information on new stuff like templates and C++'s exception handling. Still, it is a good introduction to the language that I highly recommend. Note: this book is in the process of revision to comply with the newest goings-on in the ANSI C++ committee, of which Schildt is a member. The Waite Group's New C Primer Plus, 2nd Edition by Mitchell Waite & Stephen Prata published by The Waite Group/Sams Publishing ISBN: 0-672-30319-1 There are a few classic institutions in this review, and we've just stumbled upon the first. The C Primer is one of the venerable classics that has withstood the test of time. It is one of the best general introductions to C ever. It is clear, lucid, and well-written. You can't really go wrong with this book. The second edition makes the code & teaching ANSI C conformant, and adds a little support for Macintosh C users. The book covers all the angles that Teach Yourself C does. Data types, control structures, functions, etc. It also has a good introduction to the structured programming process, and good design. The bit-fiddling chapter is a good introduction to the wonderful world of bits, and operations on things smaller than bytes. It goes beyond Teach Yourself C into data structures. There's a lot of good material at the end of the book on pointers, structs, and data structures like linked lists, stacks, queues, and trees. They have real code that implements these things. Like a lot of books in this review, they stop at binary trees and do not go into the weirder self-balancing trees and B trees. This book is also an excellent introduction to C. You won't go wrong by choosing it. The Waite Group's C++ Primer Plus by Stephen Prata published by The Waite Group ISBN: 1-878739-02-6 As I said above, there are two different approaches to learning C++. This book takes the philosophy that you can learn C++ without learning C first. It starts at ground zero and teaches you the syntax of the language. It assumes that you do not know C. It also introduces OOP from the outset, and is a great book to get you thinking like an OOP programmer. The book is very well written and very lucid, and is one of the best explanations of object oriented programming I've seen. If you have to get a book to learn about OOP and C++, this is it. The repetition (or at least ostensibly repetition) of C basics is done from an OOP standpoint. For example, Prata uses iostreams all the way through for console I/O instead of the stdlib I/O functions. By reading stuff you already (should) know from a different point of view, it helps you to start thinking in OOP terms and seeing how C++ uses OOP. #include main () { cout << "hello, world!" << endl; } A C programmer would not be able to get past "cout"... This title goes through all the C++ stuff, classes and member functions and operator overloading and all that. It's very complete, but again based on the C++ 2.something standard so it does not have the new templates and exception handling. This is the best book I know of to learn C++ with. I've seen a lot of them, and this is it. teach yourself...C by Charles Siegel published by MIS:Press ISBN: 1-55828-252-1 Before I begin the actual review, I have to admit to some editorial bias here. There is already a book called Teach Yourself C (compare to teach yourself...C). The only thing I can figure is that these people seem to want their book to impersonate the real one, which will come highly recommended because it is a great book. Otherwise, how can you explain the name? This particular book is really bright yellow, which is how you can tell it apart from the other one. The author looks at C as a great language to introduce programming in. It, unlike BASIC or Pascal, is close to the hardware, and allows the beginner to see how the computer operates. He also believes that you don't have to use C as a complex, obfuscated language and that a beginner can get by learning the basic features of the language and saving expressions like the one(s) I quote from Writing Solid Code below for later. I agree with this approach, since most programmers will be writing C code and should start early learning the language. This approach is seeped into the book. It has a few classic introductory programming problems like tic tac toe, and the bubble sort. Tic tac toe is a moronic game that is easy to program. The code is kept at BASIC level; and nothing funny with weird C operators, side-effect driven expressions, and so forth is used. This is, I guess, good for total beginners, but people programming in C need to know the idioms. I'm sure a good case could be made for and against C as a first language, and I'm sure that it has probably already been argued ad nauseam elsewhere. I do not want to try to take sides in the debate. (Although I will say I doubt if I could have handled C as a first language.) If you have to learn C as a first language, this book would be adequate, although the real Teach Yourself C would be just as good. It bothers me this book teaches bad identifier naming skills. If you're new to programming, the last thing you need to be learning is bad habits that will dog you into the future. Here is a random example from page 86 of bad naming practice: float wageWk[52]; int cntr, numofwks What's wrong? A magic number, 52. Giving some kind of symbolic name to this magic number would help in some small measure to alleviate the confusion below. Inconsistent capitalization. Why wageWk and not numOfWks? (And for that matter, why capitalize some parts of an identifier and not others, "wageWk" instead of "WageWk"?) Overloading. You assume "wks" is the plural of "wk", following "nums" as the plural of "num". This does not seem to be true, although even with the context of the program it is difficult to tell. Which leads to: no comments! If they must omit vowels and resort to cryptic abbreviations, why can't they spell it out in a comment during the declaration? What is "cntr"? Counter? Center? Siegel writes: "...but you cannot be expected to remember [another function] also used the variable cntr". I think the clinical term is suppressed memory, the horror of using "cntr" as a variable name was too much for your delicate psychological balance to take. I don't understand what the reasoning behind omitting vowels in identifiers is. It makes them unnecessarily cryptic for absolutely no good reason, since in a one-word identifier like "center" the fully-voweled version is dramatically short of the 31 significant character limit of C's namespace. Bad identifier naming seems to be a watermark of MIS:Press, see also Power Programming...Turbo C++ below. Do you want future C programmers learning to write code like this? "If variables in different modules were not segregated from each other, this program would be a mess." Unfortunately, it is anyway. I should mention that this book teaches you the infamous bubble sort, one of comp.lang.c's most well-discussed artifacts of computer science. It then discusses more efficient bubble sorts. It takes a C programmer to appreciate a more efficient bubble sort. Some of the stuff in the book is bit much, like the two-page warning for the potential horrors of pointer problems. I quote: "The real danger when you use pointers is that you might mistakenly write over data that is stored on your disk and lose it permanently." That certainly makes the novice who's never programmed before in me want to learn C! Besides which the possibility of putting the exact correct parameters into the registers of an 80x86 and then overwriting the stack with the exact same return address as the start of the interrupt for disk controlling is hard to imagine -- the author's thesis being that it is good to use C because it is close to the hardware and this scare tactic to make you not want C to be anywhere near your hardware is a bit difficult to accept. This isn't the greatest book on C I've read. Its insistence that C is a good first language is an interesting premise; but it never really follows up on that. To introduce programming the book isn't as good as some I've seen, and since it dumbs-down C to a very beginning level it is not a terribly effective first C book. teach yourself...C++ by Al Stevens published by MIS:Press ISBN: 1-55828-250-5 The first thing that I noticed about this book is that the final chapter is "An Introduction to Object Oriented Programming." That's putting the horse after the cart. But, the second thing I noticed is that it's written by Al Stevens, the well-known and well-respected Dr. Dobb's Journal C columnist, so it can't be all bad. One big plus about this book is that it's updated to include templates and exception handling. Other C++ books, especially Schildt's Complete References, are beginning to show their age. C++ has advanced to AT&T release 3.something by now, and most books on the market are still stuck at 2.something. Then again, most compilers are also stuck at 2.something. And the ones that are not generally play fast and loose with the new stuff (cf. Stevens' constant caveats about the way the Microsoft C compiler is different from the AT&T version). Of course, without an ANSI standard, an argument could be made for waiting until the standard is finalized before doing an up-to-date book. Features come and go, and different compiler developers do things differently at this time. No one really "correctly" implements exception handling and so forth. I do not know if exception handling is going to catch on or not. It seems like an egregiously clumsy way to do things, especially overused as it seems like it will be by Microsoft in their Windows classes. If it can be restrained to work in the same functionality as setjmp/longjmp, it should be okay, but it appears that -- from the examples I've seen both in this book and other places -- it will be used as a function call and switch statement for the return value. I think it is too early to tell, really, how exception handling will be used and received. The chapter on references is the best explanation I've ever seen of them. They're very confusing to C programmers, because to do C you had to forget all you knew about VAR parameters and how they behaved. Also, Pascal doesn't let you use VAR parameters anywhere you want to like C does with references. If C restricted references to function return values and parameters, it would be a lot easier to figure them out. In fact, if books would restrict their discussion of references to functions it would be nice. Trying to explain references by using them as variables in main() and then saying "but they're never used that way" is not a good strategy. Stevens does a good job when he clearly delineates the things references can and can't do. I guess the problem I have with this book is that it does not allow you to teach yourself C++ in any significant way, it allows you to teach yourself the additional features of C++ that makes it a better C. Without getting into OOP, you haven't really taught yourself anything. References, Templates, and Exceptions would be a much more accurate title. Unfortunately, teach yourself...C++ does not emphasize object oriented programming much. And when it does, it is done very incidentally. If you're wanting to learn OOP principles, you need to look elsewhere. If you want a good explanation of references, and of the newer templates and exception handling, this is the book. Caveat: this book includes a disk. It's $30, compared to $22 for its C counterpart which comes sans disk. (At the time of this writing, anyway.) Ouch! And for what? A $1 floppy disk, and code that has already been typed in to be included in the book? This isn't just this book's fault. Most books with disks are around $10 more than their sans disk peers. But, the steep price makes it less attractive to people who would want to just read about templates and stuff. While we're talking about Al Stevens, you'd think his column in Dr. Dobbs' Journal would be about C programming, or even C/C++ programming. It's sort of a misnomer, since in the entire time I've been following the magazine, the column has been about doing certain specific projects in C/C++, sort of case studies. In fact, some things are almost better for books than serialized columns that spread out over years. If you're looking for a column on C programming in the sense of tips, tricks, caveats, and other revealed knowledge about the language, PC-lint's bugs will probably be more what you're looking for. Stevens' column isn't that useful for beginners. (Or people with short attention spans!) Fin Is it possible to become too object oriented? I'm not sure. Maybe one day, a programmer will be so far into the OOP mindset that it won't be possible to follow a recipe any longer. "Let's see, I send a salt message to the stew object, and ..." Doing anything procedural will no longer be possible, because the brain of the programmer will have totally re-wired itself. At any rate, hopefully this will be enough to get you started on either C or C++. Intermediate C I feel that these books are the next step, once you've learned C enough to function and want to learn more. These books will help you develop your style, and debugging methods. Once you've learned the basics, and are comfortable with the features of the language and can think like a C programmer, these books will make you a good C programmer by teaching you more about the language. K&R (The C Programming Language) by Brian W. Kernighan and Dennis M. Ritchie published by Prentice Hall ISBN: ??? Note: the actual name of this book is "The C Programming Language". It is known as K&R, though, universally. An older name is "the white book" but 99.99999999% off all times this book is referred to, the name K&R is used. I put this volume in the intermediate category because it is challenging. C programmers who want to call themselves C programmers must read this book, though, because it is the book about C. It was written by the people who also created C. (Kernighan was mainly responsible for the tutorial part, and Ritchie in large part wrote the language reference in the back.) It is revealed knowledge that changed computers forever. Anyone who wants to truly know C must read this book, because it was written by the people who know C better than anyone. The exercises provided are designed to make you think about the language and about how C works. Stuff you'll be doing includes writing I/O functions and a memory allocator. The experience this book provides is invaluable. The second edition of this book is updated to take into account the ANSI C standard (like most of the second editions in this review), but I think C programmers should read the original. Not just as a learning tool, but as a book about your history as a programmer. As anyone who's used Windows NT or OSF/1 will tell you, those who don't learn from the past are doomed to repeat it. The book is a hallowed text that lets you see what it was like for early pioneers who read about the first high level language written expressly for programmers. Even though parts of it may be superseded by ANSI and modern compilers, this is it, the book. It inspired millions of UNIX programmers, the people who wrote Turbo C and other C compilers that brought C to the PC, and is one of the most important documents to ever be written in the field of computer science. Christians have the Bible to read, and C programmers have K&R. Other books written by scholars interpret the Bible, but only the Bible is the real thing. That's the case with K&R. C: The Complete Reference interprets it, but is not the same thing. (Incidentally, this is one reason you should get more than one book on learning C. The authors are interpreting the holy scriptures for you much like a preacher writes a sermon to explain a passage or event in the Bible. You wouldn't listen to one preacher exclusively and ignore all others, and you shouldn't with C either. If you think I'm laying on the religious analogy a little thick here, I'm not. People get as zealous over their programming language as they do over religious issues. Flame wars over vi vs. emacs have outstripped the 30 Years War in sheer meanness.) The C Programming Language 2nd Edition by Brian W. Kernighan and Dennis Ritchie published by Prentice Hall ISBN: 0-13-110370-9 K&R 2nd Edition is no longer the definitive last word on C. That distinction falls to the ANSI C standard on which this book is based. Nevertheless, it is still required reading. Incidentally, if you wonder why this review is set in easy-to-read Courier New type, K&R is a good example. It is set in Times Roman, which may have looked okay on a full-sized page, but when photoreduced to the size of this book's pages, becomes very very hard to read. I don't see why the book wasn't reset in a legible type for the second edition. It is a grave discourtesy for Prentice Hall to neglect such an important book this badly. The Development of the C Language Corollary to K&R: "The Development of the C Language" is a fascinating paper written by Dennis M. Ritchie on how C came to be what it is. It traces the evolution of BCPL into B, and finally into C. If you're interested in C at all, this paper helps to explain some things about C that may seem strange unless you know the historical backdrop that C evolved from. (One example is pre-ANSI C's incredible lack of type checking -- which comes from its predecessors, which had no data types at all other than the machine word. They even had separate operators for integer and floating point arithmetic operations. Another example is where a.out comes from.) You'll appreciate C better for having read this. You can FTP this as a PostScript file from netlib.att.com in some strange directory. It is essential reading. C: The Complete Reference by Herbert Schildt published by Osborne/McGraw-Hill ISBN: 0-07-881538-X One of the classic works that should be on every programmer's bookshelf. This is not a tutorial, but a reference for C programmers who want to look up details about the language. The second edition of this book, the only one you'll (likely) find now, is up to date on ANSI C. This is where you go for all the pesky C questions that bother you. A one-stop reference. How does varargs work? What's the exact syntax of setjmp/longjmp? Where does the FILE pointer go in the argument list to those bizarre stdio functions? (The last one is easy -- just guess first or last. Whatever you guess, pick the other one. You'll have a 50-50 chance of being right.) I'd say that reading this book would answer 90% of all the beginner/learning C questions in the C newsgroup. Part One covers C itself, all the stuff you already know about expressions, control statements, loops, arrays, strings, pointers, functions, structures, unions, I/O, etc. This is a very complete and very thorough reference. It should answer any syntax or philosophy concept questions a C programmer would have. How does something work? This tells you. Part Two covers the C standard library, and common DOS extensions. All non-ANSI functions are very explicitly labeled as such. This book, as well as most Osborne books, is biased towards DOS and the PC environment. This section covers all the standard library functions, and is an indispensable guide to them. Part Three covers algorithms. This is the weakest material in the book, because it doesn't go very far. It's primarily for beginners, not for expert C programmers. Sorting covers most of the main sorting algorithms: bubble, selection, insertion, shell, and quicksort. No heap or merge sorts to be found. The material on data structures is a little weak too. Stacks, queues, linked lists, doubly linked lists, and binary trees are covered -- but he stops before getting into the weirder self-balancing trees and B trees. Certainly nothing about ISAM or DBF type sorts. The chapter on expression parsing is very interesting. It's a very lucid explanation of a strange and wonderful subject. And it's done entirely in C, no yacc. It is something worthwhile to read. Like most (if not all) of Schildt's books, the DOS bias is very pronounced. Chapter 24 discusses the strange segment/offset addressing that the 80x86 processors use. And DOS system calls. The discussion of how to use BIOS calls to get scan codes for the extended PC keys (F1-12, Home, Page Up, etc.) is enlightening. (He forgot one way to get a list of all the scan codes -- steal them from one of Turbo C's example programs!) The graphics chapter is very low-level stuff (e.g. algorithms for scan converting lines), and though it reflects a DOS bias, it is so low-level that it would not be difficult to port. The material herein is very basic, and not of much use except to get you curious enough to read a dedicated book on graphics. I'm not sure why this was even included, since it isn't really reference material, it's the first couple of chapters from a book on raster graphics. Any graphics programming done in C on a PC would probably be using an existing library like Turbo C's BGI. Schildt becomes much more effective on graphics in Turbo C/C++: The Complete Reference where there's no war between compiler-specific functions and trying to be a book on ANSI C. The next section covers the interface C code to assembly language code. Schildt's advice is "don't do it; it creates too many problems!" but goes ahead and shows you how anyway. I tend to leave it at "don't do it." Borland provides tons of functions to be the interface between assembler and you, callable from your C code. This information is deeply DOS specific. The best advice here is to use the C compiler to generate the skeleton of the thing you want to write in assembler, then edit the assembly language listing the compiler creates. The advice on efficiency is somewhat outdated, since the 486 and Pentium chips are a lot different than the chips this book was written using. And compilers have gotten a heck of a lot smarter at writing efficient assembler than people are. The advice applies mostly to older CISC architectures, and dumber C compilers. Now, if you're using a current compiler on the market, I would seriously advise you to write as straightforward code as you possibly can, and turn on all optimizations. The compiler, which was written by people who are smarter than you'll ever be, can out-do you in code-generation every time. If you think you're smarter than the compiler, go work for a compiler company so everyone can reap the rewards. The book ends with a brief overview of C++, and how using object oriented programming can make your programming easier. It is enough to get a "covers C++" billing on the cover, but it is a survey of the language to introduce C programmers to it and see if they want to go further. Schildt's books are known for their bad typesetting, leading to some bizarre looking code. You wonder if he's the only one who knows anything about C working on the books. My favorite one is a comment that left the * out of */ -- but the next line was another comment and nothing else, so the code would still compile and run okay! (You don't know how much I wish I knew what page this was on!) C++: The Complete Reference by Herbert Schildt published by Osborne/McGraw-Hill ISBN: ??? Similar to its counterpart, but for C++ and not C. I don't actually have this, but have read most of the contents of it from Turbo C++: the Complete Reference (q.v. in the Other Books section). If I could get a copy of it specifically, I'd review it more fully. C and C++: The Pocket Reference by Herbert Schildt published by Osborne/McGraw-Hill ISBN: ??? and ??? Obviously, McGraw-Hill feels that too much of a good thing is perfectly okay. These books are condensed versions of their respective Complete References, the same text but heavily edited to fit in a small, pocket-sized package. If you ever have to write C programs on a laptop on an airplane, they have what you need. I've thumbed through this, and it's just a Reader's Digest Condensed Books version of the bigger relative. Practical C by Steve Oualline published by O'Reilley & Assoc. ISBN: 1-56592-035-X Practical C is in the intermediate section, even though the back cover bills it as an introductory book. I don't think you could really get the most this book can offer without some basic knowledge of C under your belt. You might be able to read through it -- but if you already know the basics, you'll really get a lot out of it. You'll learn something more than just the basics. And that's this book's strength. This is one of the best books I've ever read about writing good, easy to read, maintainable C code. It's packed with a lot of advice that comes from experience. The practical aspect is what makes the book good. There are just thousands of really practical, useful pieces of advice in this book. Here's a sample: ...however, using ++ or -- [...] can lead to some surprising code: o = --o - o--; The problem with this is that it looks like someone is writing Morse code. The programmer doesn't read this statement, but rather decodes it. If we never use ++ or -- as part of any other statement... Pointers are explained in what is one of the most effective uses of graphics I've seen to explain anything. Usually, pictures make pointers more confusing than they are to begin with, but these pictures really do a good job in explaining the logical view of pointers programmers need to understand. The 3D boxes are a big help. If you've read one of the introductory books and are confused by pointers, then reading this will help you. I find the dusty corners section kind of funny. I've never noticed any programmer aversion to the ternary operator, ?:, at all. Most people enjoy using it. (My favorite use of it is in a printf statement like: printf("%d bytes in %d %s selected\n", num_bytes, num_files, (num_files ==1)? "file":"files"); because laziness in plurals is inexcusable. "Delete 1 files?") I particularly like Oualline's being a proponent of while (1) instead of for(;;). I like that construct, and "while 1" really shouts out "infinite loop!" to me, a lot more than for(;;) does-- it shouts out "you forgot something" to me. Some things the book does seem to defeat the "practical" purpose, such as casting all functions whose return values are ignored to void. This includes printf and every other I/O function! The code is weighed down in these casted calls. And, there's a big old cow on the cover! Effective C++ Programming by Scott Meyers published by Addison-Wesley (Professional Computing Series) ISBN: 0-201-56364-9 Let me issue a caveat: after reading this book, my new feeling is you can't really learn C++ from an introductory book very well. Introductory books are good for teaching the syntax, but for the real concepts behind how to put C++ to use, you need to go one step further. I won't note all 50 effective points made. The most important thing this book does is clarify what object oriented relationship models there are (isa, hasa, is-implemented-in-terms-of) and what specific features of C++ exist to implement these features. Understand this is crucial to using C++ effectively, and a great majority of the book is devoted to this topic. C Elements of Style by Steve Oualline M&T Books ISBN: 1-55851-291-8 Steve Oualline is on a mission, to make programmers aware that it is their duty to write decent code that other programmers can modify easily. Oualline has been in the trenches collecting war stories, and like most books written from practical experience, it is worthwhile. Reading this book is an eye opening experience. >From the introduction: This book describes a programming style I've developed over the years by working on thousands of lines of C code. I've spent a lot of time going though other people's code, and I've seen the good, the bad, and the ugly. ... Also, in going through other people's code I have had the opportunity to examine their styles. Over the years, I have seen a lot of different approaches to programming style. Some have worked, some haven't. ... Whenever I screw up, I ask myself, "Why did I make this error? Is there any way I could change my programming style to eliminate the possibility of that kind of error...?" The best thing about C Elements of Style and Practical C is that it makes sense. When you read it, you think that it is correct, the way things should be, because the suggestions make sense and the alternatives don't. You may not have thought of it before (or you could already be doing it and not realize it), but once you realize it, you see why it's a good idea. In C Elements of Style, Oualline omits the introductory material and the pointer diagrams, and instead concentrates on style. He assumes you already know how to write C code, and that you want to learn how to write it better. And he delivers some very solid stylistic advice that is based on the single most convincing argument in the world: it has been tested in real code, and it works. If you can prove that some advice will let you write better code, it is difficult to find any reason not to do it. Oualline manages to create heuristics (a "heuristic" is a rule of thumb) that are profoundly insightful and phrased in a very entertaining manner. Here are two: C has 21 precedence rules (<< comes before ||, etc.). I can't memorize all these rules, so I have learned a simple subset: 1) * % / come before + and - 2) put () around everything else Oualline's law of documentation states: 90 percent of the time, the documentation is lost. Of the remaining 10 percent, 9 percent of the time the documentation is for a different version of the software and is completely useless. The 1 percent of the time you have the correct documentation, it is written in Chinese. And he even gives some C++ advice. If anything needs good style, it is C++, the result of trying to make C object oriented. Here's my favorite example: Public vs. private Question: In the following class, is counter public, private, or protected? class fun { int counter; // What is this? // ... } Answers: A) public, because the C++ default is public. B) private, because the C++ default is private. C) protected, because the C++ default is protected. D) If you don't write code like this, you don't have to worry about this question. This kind of fun-to-read but very pointed quiz is typical of the book's insides. (The answer, by the way, depends on whether the class is declared with the keyword class or struct. One is private and one is public.) I don't agree with everything Oualline has to say. The point, though, is not that you agree with him, but that you are aware of the issues he raises and are doing something to make your code better. If you put one or two things in this book to use, you'll be doing the world a big favor. If you take this book as a starting point to making active and aware decisions about what you type in, you'll really be doing a good job! Interesting factoid: The technical editor of this book was Dr. Dobbs' Editor-at-Large Michael Swaine. C++ Programming Style by Tom Cargill published by Addison-Wesley (Professional Computing Series) ISBN: 0-201-56365-7 If anything needs a style guide, it's C++. It is not difficult to write bad C++ code, even if you know (or think you know) what you're doing. C++ is a very young language (only about 10 years old, compare to C's 20+), though, and things are still being hammered out. But some basic stylistic concepts are emerging. Writing Solid Code by Steve Maguire published by Microsoft Press ISBN: 1-55615-551-4 Speaking of being active and aware, there is one book that will open your eyes. If you have to read one C book on the intermediate level, Writing Solid Code is it. This book complements Oualline's books. They're both about style and the issues of making a program correct. Oualline's books focus mostly on making the code readable and maintainable. Maguire focuses on the code doing what it is meant to. They both dance around the same subject (good programming) in different ways. If there were some way to make every C programmer have to read this book, I'd support it. Maybe a license to code in C for which you have to pass a test? Anyway, Microsoft is known for releasing buggy code, as any Word 6.0 user will testify to, and Maguire is someone with tremendous experience in coding good code. He was working for Microsoft, and started noticing the "old guard" programmers (who were the original people working at the company) were being dwarfed by newer coders hired in MS's phenomenal growth who had not been socialized in the informal techniques of coding that had developed at Microsoft. The older programmers had developed a lot of wisdom, and had passed it along informally via word-of-mouth type techniques, not codified standards. With explosive growth, this informal system quit working effectively, and the result was very easy to notice in the marketplace when MS products were scrapped because of bugs. Maguire set out to catalogue formally in one book all the techniques he has learned through experience. These are not syntax debugging tips, such as == vs = or problems with gets(); but rather philosophical debugging ideas. The writing style of this book is excellent. It is informal, spirited, and even hilarious at some points. He does not neglect attention to detail, either, and it is obvious that a lot of serious thought went into the topics included. To pull this off in a technical book is truly a feat. Maguire has done a tremendous service to C programmers everywhere. Let me mention a few of the topics covered. Assertions are talked about in depth, and their use is explained very well. You need assertions in C code to tell where and why things bomb. Fortifying subsystems is a strategy to eliminate undefined behavior and validate and otherwise check data passed into your functions from elsewhere in the program. The best defense is a good offense. Also, designing good interfaces helps eliminate errors via providing consistency. Eliminating risk through the elimination of confusing and tricky code is a good section. The section on making things go "faster" and the perils that can result is an important one to read if you like to write "optimized" C code. The attitude emphasis in the book is the important thing to get from it. Writing Solid Code will make you aware of things that either you didn't know about, or things that you knew about instinctively but didn't know that you did on a conscious level. It is up to you to make sure that when you sit down to write code, you consciously think about what you are writing and make informed decisions. There are some great examples of patented Stupid C Tricks in here (such as using the ?: operator to select which of two functions you want to call based on the test condition: ((sin_wave)?sin:cos)(theta); Yes, that's legal. (By the way, he uses these examples to explain what not to do -- I have a feeling that it will have the reverse effect on programmers! Some of the tricks are really neat.) Code Complete by Steve McConnell published by Microsoft Press ISBN: 1-55615-484-4 After agonizing over whether or not to include this book in a C review, I finally decided that I should. Unequivocably, Code Complete is required reading for anyone who writes C code. Nothing comparable exists, which is why McConnell says that he wrote the book. McConnell's index and bibliography listings in the chapters is incredibly complete and one of the most amazing things I have ever seen. Just compiling the bibliography alone would be more than reason for writing the book! No matter what topic is brought up, pointers are included to books, articles, and other sources for more information. Fin I believe that Writing Solid Code and C Elements of Style are required reading for C programmers. You should have C: The Complete Reference on your shelf. Advanced C Advanced C books are categorized as books that allow you to do advanced things from the world of computer science, like implementing data structures and using modular programming techniques. This has proven to be the most difficult part of this review to write, for two reasons. First, books on "advanced" topics are hard to come by as a rule, since the average Waldenbooks doesn't stock them. Second, the books I have found turned out to be, for the most part, vastly disappointing. Advanced C by Herbert Schildt published by Osborne/McGraw-Hill ISBN: 0-07-881348-4 Acknowledgment: Thanks to Peter Schmitt of Dartmouth College, who happened to be liquidating his computer book collection at the same time I was trying to find this book. What we have here is a tremendously moot point. This book is out of print! The first advanced C book I found is not even available. Nothing like getting off to a good start. You aren't missing much by this book not being around: most of this book is lifted almost exactly word-for-word from C: The Complete Reference. (Or vise versa.) And, although this is a second edition, and claims to have ANSI C code in it, that is true only in the loose sense that ANSI C is backwards compatible with K&R C. The book uses the old style function declarations exclusively. The reason for this is because the book was written when the standard was still being hammered out. It has not been updated since then, for reasons that will become apparent in the review below. One of the best chapters is chapter 6: statistics. This is about the most interesting chapter in the whole book. It discusses the mean (average), standard deviation (average of the average), median (the middle point), and a little bit on how to interpret these numbers. There is full code for doing the standard deviation, which is a fairly complex formula. [There's a formula in the PostScript version here!] Where: D is the set of all the data in the sample i is the index into D N is the number of elements in the sample M is the mean of the sample This is not a fun thing to write in C, because you're using powers, and they're computationally expensive. Translating an equation into a C function is an interesting excercise. There's probably some way to re-write the equation above to use absolute value instead of squaring and then square rooting to obtain a positive number. But, as the implementation below plays out, the cost of the computations isn't that bad. The way Schildt does it, along with my notes: [My notes deleted in ASCII version] /* Compute the standard deviation */ float std_dev(data, num) float *data; int num; { register int i; float std, avg; double tmp, sqrt(); avg = mean(data, num); /* get average */ std = 0; for (t=0; t