C Books and C++ Books You Don't Want | Hacker News Reader

C Books and C++ Books You Don't Want

cs.technion.ac.il

59 pointsekm239 comments

I love books that go straight to the point. I appreciate terseness, and appreciate it orders of magnitude more when it comes with no loss in clarity. Its amazing what some authors can pull off with so few words.

You can guess K&R is one of my favorites.

I understand that C++ is a huge complicated language, Scott Meyers puts it very aptly by stating its a federation of languages, and this makes hard to write pithy pedagogic books. In spite of that, the ever too common 800+ page tomes have always worked against me.

Stroustrup's 3rd is probably a mighty fine book to learn from, its just not for me and its definitely no K&R.

I think my favorite is a little known book by Dirk Vermier http://books.google.com/books/about/Multi_Paradigm_Programmi... It should definitely not be one's first programming book, perhaps not even one's first C++ book. A shade shy of 300 pages, it did serve me well with its terseness, correctness and clarity. The only thing is that its too pricey for its size, its a bit dated now because it covers c++98.

I think C++ is best understood from one pithy book that shows you the just the language to get started, and then a series of Scott Meyers, Andrei Alexandrescu, Herb Sutter style books to get good at it.

"Accelerated C++" by Andrew Koenig and Barbara Moo is pretty good and somewhat along the lines of K&R.

there should be a new version for "accelerated c++" hopefully soon,

i have sent koenig an email asking about this, and he replied, and said he will start working on a new version with barbara moo as soon as she finishes working on the new version of C++ Primer

I second this comment! Excellent book that will have you up and writing idiomatic C++ in no time.

I definitely found this an excellent read as well.

AFAIK worst book on C Programming Language in existance is "Let Us C" By "Yashavant Kanetkar"

http://www.ksetindia.com/books/let-us-c

Ironically this book is quite popular with students in Indian Universities (I guess mainly due to ignorance)

Even the wikipedia page for the author admits this fact

http://en.wikipedia.org/wiki/Yashavant_Kanetkar

That guy has written more than 40 books according to Wikipedia - quantity over quality, I suppose. I wonder how he justifies having 9 editions for "Let Us C". It's almost as if he is doing solely to be able to force students to buy the new version (as opposed to the used version in the university bookstore).

Correct. And the general misconception among students is that the newer editions contains contain updated stuff.

The gross thing is that the content is toatally based on Turbo C/C++ compiler for windows and is full of errors, with no attention paid to standards

The high-school C++ curriculum in India is taught on Turbo C++.

Your profile looks interesting. I too am passionate about programming and have been dabbeling into LISP for some time. Where can I find your contact info ?

This web page is really quite awful. There's no sense of a uniform level of treatment -- there's a condemnation of assert() right next to page-by-page book errata. The comments are not incisive at all. There's no table of contents. And the rotating gifs.

"There's no table of contents." Really? Did you look at the top?

You are right. Of course, the page is still a travesty of form and content.

I remember using the SAMs books (which make the list). I learned more from correcting the errors, of which there were many, than I did from the books themselves. Simply horrid books that should have had much more time spent on editing.

SAMS, Cue, Cybex, Wrox: the doorstop publishers!

Wrox actually has some nice books, especially in the C#, Java department that I know of.

He lost me at this -

> assert is used for algorithmic error detecting instead of for debugging only. This is a serious error, common to many, otherwise good, books. But here it is very widely used.

One man's error is another man's programming style. Using asserts as comment-like statements to declare invariants is a very useful a well-established practice that leads to a more concise code. Perhaps it's a nuance not fit for the novices, but to call a book bad because if that is unreasonable at best.

I think you missed the point: I agree that using assert() is good for declaring invariants - but it is used only at debugging (as the quoted text says). If you don't turn assert() off at production (NDEBUG) you are in a deeper problem. The main thing should be that assert() does not replace if() or other conditionals (say for testing successful scanf()), and moreover, assert() should be used in a textbook when teaching debugging - not when teaching the basics of programming (likewise, only a very advanced student-driver is taught how to restart a stalled engine while in 60mph motion on the freeway - not a beginner one).

> If you don't turn assert() off at production (NDEBUG) you are in a deeper problem

In a deeper problem compared to when I don't turn it off? Are you sure about that? The only reason asserts are turned off in the production code is the performance considerations, nothing else.

Sorry to hear that. The problem with assert() at production code is that it crashes the program. IMNSHO, it's a medicine worse than the disease (is this why we get a "blue screen" on a popular OS?). Most, if not all tools should be lenient about errors - both user errors and system/environment errors - not just safety systems. There are very few cases that a tool should say "there is a problem, please contact the vendor" - and even then it is unreasonable to do it while crashing (maybe the user is willing to give up the last task but wants to start over with a different task). If you are not convinced, I am not able to explain it in any simpler and clearer way. Thanks for your time.

"Sorry to hear that"? Seriously?

You have fundamental misunderstanding of what asserts() are for. As GP said, they check for invariants not errors. Here -

  +--------------------------------+
  |                                |
  |   ASSERTS ENFORCE INVARIANTS   |
  |                                |
  +--------------------------------+

They aren't meant for checking if socket() returned -1 or user entered an empty string. These are not invariants. An invariant is a condition that must always hold true or the code that follows will go off rails. An ordered list to be ordered, a pointer passed to a function to be pointing at a valid and consistent representation of a respective data type... this sort of thing. A foo(void * ptr) not being called with NULL may or may not be an invariant depending on what foo's documentation states. For internal code it probably will be, for a library version is probably won't. In any case, these invariants is what you assert().

If your code runs into a broken invariant and you let it continue forward, you simply push the problem deeper and let it metastasize. Compare abort'ing program to letting it go on, fubar'ing user data and then over-writing a disk file with the resulting garbage. A medicine worse than a disease, eh?

Well, I find this discussion very interesting - esp. because it reveals so many misconceptions about programming in a tiny nutshell. Let me start by emphasizing that you were reading into the previous comment something the author didn't write. "If your code runs into a broken invariant and you let it continue forward ..." - I don't see anything even remotely associated with it: The claim was just that "abort()" in most cases is too strong a response. Indeed "ASSERTS ENFORCE INVARIANTS" - but during debugging. And invariants may be enforced using different mechanisms, assert(), as a very general tool/technique is simply and understandably very crude. My view of assert() is two fold: 1. It's a shotgun. In real life not every "crime" deserves capital punishment (and not all broken invariants are the same). 2. All asserts are connected: They can only be turned on/off together (yes, you may use conditional compilation to overcome this problem, but in this case conditional compilation can be used for just a better system - where there are various severity levels for asserts).

All you have to realize is that not all problems need the same cure. Using your example, if it is found that a list broke it's invariant, isn't it enough to stop using this list (isolating it, not freeing it) and then gracefully terminate the program? There is more to elaborate here, but most readers can draw the correct conclusions. Maybe this discussions exposes how much more we need to learn about software quality - where my page on bad books (the ones I have encountered) is just a very narrow opening to the real problems.

Best c++ book is "The c++ programming language" by Bjarne.

I own the 3rd special edition: http://www.bookdepository.co.uk/C-Programming-Language-Speci...

and have pre-ordered the 4th edition which includes c++11 info: http://www.bookdepository.co.uk/C-Programming-Language-Bjarn...

I've only probably read like 5 c++ books, but this one kills all the others for explaining how things work, teaching good programming style, and giving you a great all round understanding.

Interestingly, "C++ For Dummies" is absent. I wonder if he just missed it, or really thinks it's not that bad. I learned C++ from it, and I think it did a decent job.

Ha! I still have a Schildt C/C++ book on my shelf. I used it back when I was learning C with Mark Williams C on my Atari ST. Probably about time to retire it to the landfill.

Thank you for the article. Many of us share the hatred for Microsoft Corporation but perhaps we should let go of the M$ shorthand out of context?

The article was written in 1998 when such slang was common, as was the design elements used (like animated gifs).

I don't think being disdainful of Microsoft is interesting either but it makes more sense in context.

totally... it's irrelevant now. The company has really changed and besides can we really say that they were that bad now? Is Microsoft Windows really such a bad product? I personally don't think so.

I learned a ton from SAMS "teach yoursefl C++ in 21 days". Yeah I didn't think I would either, but it was given to me at work, and I went through about 75% of it and it was pretty damn good.

I've read two of the books on this list and both, while having their faults, were very useful and helped jumpstart my programming experience in my teenage years. The things this person is complaining about are limited to a tiny minority of pages regarding unspecific topics that changed significantly over time and were not necessarily incorrect when written.

Overall, the website comes across as bitchy and pretentious. especially considering how their own HTML comes across as flagrantly hideous.

Rants about void main seem archaic, unjustified, and pretentious.

How so? The argument as I understand it is that all C89 standard-compliant compilers work with "int main" (and work correctly), regardless of whether or not the target OS has exit statuses. Not all compilers work with "void main", and those that do will yield executables that always produce an exit status of zero. While there are times you might write C code that doesn't need to be portable (in which case "int main" and "void main" are effectively the same if your system doesn't use exit statuses), there is no good reason for a C textbook to teach the non-standard approach that only works in certain non-portable cases. If a textbook does so, that's likely a sign that the authors made other poor decisions.

No, compilers that accept "void main" do not necessarily produce executables that produce an exit status of 0. I just tried it with gcc on Ubuntu, and the exit status was 1.

And the validity of "void main" doesn't depend on whether the system uses exit statuses. An implementation may accept forms of main other than the ones defined by the language, including "void main()" -- but if it doesn't, the behavior of such a program is undefined.

The rules are different for freestanding implementations, which are generally for embedded systems; for such systems, the program entry point is entirely implementation-defined, and might not even be called "main". But for hosted implementations, there's no advantage at all in using "void main" vs. the correct "int main(void)".

> No, compilers that accept "void main" do not necessarily produce executables that produce an exit status of 0. I just tried it with gcc on Ubuntu, and the exit status was 1.

Interesting. I wonder why gcc does it that way.

> And the validity of "void main" doesn't depend on whether the system uses exit statuses. An implementation may accept forms of main other than the ones defined by the language, including "void main()" -- but if it doesn't, the behavior of such a program is undefined.

I don't think we're disagreeing. I'm saying that "void main" is never preferable to "int main", and the only time it's equal to "int main" is if you're writing code specific to an implementation for which "void main" is not undefined and which lacks exit statuses, making any return statement in "int main" equivalent to returning from "void main".

> But for hosted implementations, there's no advantage at all in using "void main" vs. the correct "int main(void)".

Agreed. That's why it makes no sense for textbooks to teach void main.

Agree. I've used "void main(void)" on embedded applications where 1. there is no OS under you. 2. it can never "exit"

void main(void) { init(); for(;;) { web_tick(); serial_tick(); tcp_tick(); etc. } }

An example is the horrible Dynamic C compiler from z-world (or digi as they are now called). Guys who complain about "violating standards" clearly haven't worked in diverse enough fields on broken, shitty and half-standard compilers ;)

This list is unfortunately missing the O'Reilly-published "Practical C++ Programming" by Steve Oualline, which is a truly terrible text, and the only O'Reilly book I actively tell people to burn. It's filled with errors, code samples riddled with syntax errors, and non-idiomatic style.

Didn't everybody in the world already know K&R is the only C book worth touching?

Not really. You need at least "The C Programming FAQ", by Steve Summit (it has a very useful Internet (partial) version) and one or two more. Those who understand K&R2 and C-FAQs know better than 90% of C programmers.

Without looking at the list I K&R isn't on it. It's really all you need to get started, you can find code snippets and experiment to get past that.

Has anyone noticed how many books on C are 4 times the size yet leave you with less valuable information than K&R?

Reply on news.ycombinator.com