Bests & Worsts Reviews from Amazon

I was looking for a book to bring my 1990s-era C and C++ knowledge up to date and ordered this book. The more I read, the angrier I got. I knew from the reviews that this book wasn't an updated K&R, but it had good reviews for the material I wanted to learn. It also covers tools (make, autoconf, git), and I thought that refreshers on those topics would be useful, so I ordered the book. The title of the book is "21st Century C". That name implies coverage of post-K&R features through C11. But that information is buried inside so much useless glop. The title might also refer to the aforementioned tools. However, the title seems to also cover the author's idiosnycratic and macro-heavy approach to using the language. I have no idea if this is really how modern C is done, but my impression is that this usage is not typical. As the book goes on, the examples get longer and the content I'm after gets sparser. So I ended up skimming the book pretty rapidly. My first sign of trouble was the discussion of compilation. I am by no means an expert on makefiles, but even I could tell there was a serious deficiency. After introducing the basics, and showing how make handles .o dependencies on .c, the book has a minimal standard makefile for use in day-to-day work. Except that there is no discussion of dependencies on header files. None. I went back and reread the chapter, and it's just missing. No entry on header files and dependencies in the index. But there are discussions of other obscure topics, like specifying header files to be included via environment variables, and compiling "here documents". If you are going to cover the C programming environment, then the missing discussion of dependencies is a mind-bogglingly huge omission. And it will have real consequences as beginners tear their hair out trying to figure out why their header file changes aren't fixing their compile-time errors. But what finally pushed me to write this review was the following paragraph (page 266), which is part of a discussion of hash tables: "For any hash, there is still some chance of hash collisions, although it is very small for a reaonably written hash. I use hashes like the ones above in my code, and I am aware that there is some small chance that one day somebody will get unlucky and hit on two sets of points that cause a hash collision. But when deciding where to allocate my finite time on this Earth, I can always find another bug fix, feature implemenation, documentation addition, or personal interaction that will provide a greater benefit for a greater number of users that would eliminating the chance of hash collision. Git relies on hashes to [sic] record commits, and users have produced millions (billions?) of commits, and yet eliminating hash collisions also seems very low on the agenda of the Git maintainers." This is, by far, the stupidest paragraph I have ever seen in a technical book. 1) It confuses two completely unrelated uses of hashing: for hash tables, and for generating signatures of digital objects. 2) For hash tables -- the topic of the section -- hash functions are likely to generate collisions for two reasons. First, the hash functions are designed to be fast to compute (such as the one mentioned), and not necessarily to produce a low rate of collisions. Second, the hash values are reduced modulo the size of the hash table, so collisions in the table (different keys going to the same hash table slot) are extremely likely. Let me emphasize this point: Hashing different keys to the same hash values may be likely or unlikely, depending on the hash function. Hashing different keys to the same hash table slot is very likely, and if your hash table doesn't worry about this kind of collisions, you have a badly broken hash table. 3) The use of hashing in Git is completely different. A "secure", slower hash function (SHA-1) is used to generate signatures of files and directories, and yes, in this case collisions are spectacularly unlikely. And there is no reduction to a smaller space of values (as in a hash table). So in Git, collisions never happen. 4) The author blithely confuses these unrelated kinds of hashing, assumes that the low collision rate of one applies to the other, completely erroneously, and then says that it's not worth his valuable time to fix his hash tables collisions, (or, presumably, his ignorance.) Anyone who would write that paragraph should not be writing software, let alone, educating other people how to do it. 5) Finally, it is shocking that O'Reilly, would let this colossally stupid discussion see its way into print. Did nobody review this book? (Same applies to the makefile discussion.)