
C Books and C++ Books You Don't Want    - ekm2
http://www.cs.technion.ac.il/users/yechiel/CS/BadBooksC+C++.html
======
srean
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...](http://books.google.com/books/about/Multi_Paradigm_Programming_Using_C++.html?id=9xfGehPHFCgC)
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.

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

~~~
systems
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

------
nimeshneema
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>

~~~
metaobject
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).

~~~
nimeshneema
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

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

------
mturmon
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.

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

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

------
mikestew
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.

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

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

------
eps
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.

~~~
theobserver
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).

~~~
eps
> _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.

~~~
theobserver
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.

~~~
huhtenberg
"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?

~~~
yechielkimchi
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.

------
matiu3
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...](http://www.bookdepository.co.uk/C-Programming-Language-
Special-Edition-Bjarne-Stroustrup/9780201700732)

and have pre-ordered the 4th edition which includes c++11 info:
[http://www.bookdepository.co.uk/C-Programming-Language-
Bjarn...](http://www.bookdepository.co.uk/C-Programming-Language-Bjarne-
Stroustrup/9780321563842)

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.

------
andrewflnr
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.

------
bcl
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.

------
3825
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?

~~~
arkem
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.

------
jcmnetmedia
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.

------
gsibble
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.

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

~~~
dsrguru
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.

~~~
_kst_
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)".

~~~
dsrguru
> 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.

------
greyfade
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.

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

~~~
yechielkimchi
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.

------
Ramonaxvh
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?

