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