Effective C++, Third Edition 296
| Effective C++, Third Edition | |
| author | Scott Meyers |
| pages | 297 |
| publisher | Addison Wesley |
| rating | 9/10 for C++ programmers; not worth it otherwise |
| reviewer | nellardo |
| ISBN | 0321334876 |
| summary | Re-write of standard second book on C++ |
C++ is a large and complex language, and always has been. That's what made the first edition of Effective C++ so useful. What began as a simple concept of "C with Classes" grew as time went by, developing quirks and foibles that made sense only once you understood a great deal about what was going on. The first edition provided short, digestible synopses of the best practices of quality C++ programming. Even people that had been programming C++ for years could read the book and pick up something new.
That was 1991. A lot has changed in C++ since then. For instance, templates were only just being developed as an addition to the language, and most C++ compilers simply generated C code. Now, in 2005, C++ has gotten a great deal more complicated, and C++ templates have turned out to be a programming language in their own right. Exceptions, the Standard Template Library, threading libraries, and a wealth of truly inventive programming have turned C++ into an amalgam of concepts and mechanisms from essentially every programming language under the sun (ahem). C++ isn't quite as complex as Ada, but that's a much tougher case to make today than in 1992.
In addition, the understanding of what the best practices actually were has changed. Indeed, common tricks from 1991 are now generally frowned upon. In 1991, a friend function was common in code examples. For instance, operators were routinely declared as friend functions. Now, in 2005, friend is seen as creating the tightest coupling possible between components, and is often avoided. What happened?
This is where the book's background starts to shine. Item 1 is "View C++ as a federation of languages." Meyers does a clear and cogent job of decoding broad swathes of C++, explaining C++ as a multi-paradigm tool, and placing language features in different paradigms. Change paradigms and the guideline for what makes for effective C++ changes. This is a hard case to make, but he manages to do it in accessible language even a newbie to the language should be able to follow. Experience from 1991, 1997 (the second edition, mostly a spruce-up job of the first), and now add up to explain the boundaries.
Like earlier versions of the book, the final items provide a good hint on how to keep current. Item 54 is "Familiarize yourself with the standard library, including TR1", and Item 55 (the last) is "Familiarize yourself with Boost." Both of these point to the two places C++ is most likely to grow in the near future, TR1 being essentially done, and Boost being an active source of new things likely to make it into future language extensions.
While 55 items isn't as neat as 50 items, the items in the middle still provide a good place to start for a new C++ programmer. The experienced C++ programmer (the kind who's running around their department suggesting simply using Sutter and Alexandrescu's C++ Coding Standards as the department's new coding standards as is) may not get as much from the book, but it isn't really looking for that programmer. It is advertised as a "second book" on C++, and that's exactly what it is. Buy your textbook to learn from, then buy this book.
Can the experienced C++ programmer get something from the book? Sure, but it's more along the lines of having a handy way to explain to the new guy in the next cube why you want to make sure exceptions never leave a destructor (Item 8) rather than having to figure out a clear way to say it yourself. If nothing else, the more experienced programmer may want to read it just to know what the new guy is likely to ask about.
As a book per se, it's nicely done. It uses color judiciously, mainly to point out the most important parts of the code examples. It also includes lists of items from More Effective C++ and Effective STL, which are handy, albeit blatant plugs. More interestingly, it includes a map from the items in the first edition and the second edition to the items in the third edition (in both directions). This makes it clear that this book truly is a substantial re-write. I would have liked to see a list of all the items, along with the two or three bullets that summarize them as a separate table (maybe on the front inside cover for easy access), but that's a minor point.
All in all, Effective C++, Third Edition is exactly what it claims to be. A significant re-write of the best second book out there. Learning C++? Then pick it up. Using C++ actively with a bunch of other programmers? Pick it up. Not using C++? Don't bother.
You can purchase Effective C++, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Object-oriented design patterns. A necessity! (Score:4, Insightful)
I only have one book on programming (Score:2, Insightful)
sorry about the prev. post (Score:3, Insightful)
Once upon a time:
c+=c+++++c;
was a perfectly valid statement in the project.
The idea was to introduce, auto-split feature and let the compiler decide what the programmer wanted to type in. This would have saved programmers time and make them more productive. (Dreams, o marketing dreams).
But, how do you deal with something as:
a+= b+++c;
is it:
a+= b++ + c;
or is it:
a+=b + ++c;
It took 2 hour meeting (with 4 people) to convince the newly appointed marketing guy to leave the idea.
Re:A Good Book For The C++ Newbie? (Score:5, Insightful)
p.s. If you want an API book, buy "GUI Programming with Qt" instead. It comes with a free copy of Qt noncommercial for Windows. Your programs will be crossplatform and trivially portable to Linux, Unix and OSX. The quality of the Qt API makes MFC drop to its knees in humble supplication.
p.p.s. If you want to learn the VC++ IDE, read the help pages.
Re:Do people still write new C++ code? (Score:2, Insightful)
So when did C++ start running on bare hardware? Every time I've run it, I needed an OS and a huge pile of libraries. Is there something inherently worse or different about loading a VM than loading libraries?
"C++ is fully portable"
Because source code portability is so much easier than binary portability? Lets see you recompile something written for Windows on AIX and have it run the first time. I've done that in Java.
Re:Do people still write new C++ code? (Score:3, Insightful)
Maybe it's because some of us are writing software for the real world?
Re:Do people still write new C++ code? (Score:4, Insightful)
The reason why there are so many people around saying we should use Java and C# is ignorance. These people have never had to write code where performance matters. I work on a large graphics application that uses Python bindings to make it easy to use. But we still have to develop non-Python part using a language whose performance doesn't suck beyond belief. If we don't, then the competition will be faster.
At this point I usually have to endure the lecture about how slow code can be speeded up with good algorithms. But we have some of the best people in the field working on our algorithms and still need more speed. There is no choice but to use C++.
Re:Do people still write new C++ code? (Score:3, Insightful)
Re:Do people still write new C++ code? (Score:2, Insightful)
Mozilla Firefox/KDE?! (Score:2, Insightful)
I'm sure the Firefox and KDE folks don't need your pity.
Re:A Good Book For The C++ Newbie? (Score:4, Insightful)
by Bjarne Stroustrup
by Nicolai M. Josuttis
by Andrew Koenig and Barbara E. Moo
Stroustrup is the reference book for the language. It could be used as a textbook or tutorial since it has good pedagogy and problems to solve at the end of each section. But Koenig and Moo is better for the tutorial aspect and Stroustrup is better as a reference. Their is a paperback version of the 3rd edition, but the special edition, with its stiff spine and ribbon bookmark, is worth the money because you will be frequently referring to it.
Josuttis is the reference to the standard library and standard template library. This is an advanced book, and could probably be the last one of these you purchase. He covers everything the C++ standard library has to offer, especially including templates. Don't worry about these too much as you start out. Stroustrup and Koenig and Moo both touch on these topics and give a gentler introduction.
Koenig and Moo is the tutorial that every C++ programmer should start with, IMHO, and should be the standard intro university text. It doesn't carry baggage from other languages or bad style. Even though you've gotten through Deitel, I'd suggest going through Koenig and Moo next, skipping Horton completely.
Meyers two books used to be the standard on best practice. I guess this new 3rd edition, of which I was not aware, is the new standard. There are some things you can do in c++ that you shouldn't do, as well as some pitfalls that can be avoided if you are aware of them. Meyers points these out and is essential to creating strong code. I would get the new 3rd edition of Effective C++ and wait on More Effective C++ until it comes out in 3rd edition.
To sum up: Go through Keonig and Moo first to learn the language, but get Stroustrup at the same time to use as your reference. Pick up Myers 3rd edition when you finish Keonig and Moo, then start working through the problems in Stroustrup. As you get to the advanced sections of Stroustrup, pick up Josuttis to use as an additional reference. When you've finished all of these you should be very well versed in c++ and a better c++ programmer than probably 80% of the coders out there.
If you are done with school and out there working, you should be able to get through these in about a year of independent study. If you are still in school, focus on the classes you are paying for, and use these books as outside reading and references to inform your classwork.
Some other books to check out:
The C Programming Language by Brian Kernighan and Dennis Ritchie and The C Standard Library by P.J. Plauger. This is actually a great place to start learning to program, since you work very close to the hardware, but in a much more portable fashion than assembly.
Code Complete, Second Edition by Steve McConnell and The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt. These contain essential knowledge about being a programmer beyond the nuts and bolts of the code. Reading these and applying the knowledge to your work will take you into 90% territory.
I hope you found this useful and that this helps guide you to where you want to be.
Re:I only have one book on programming (Score:5, Insightful)
Do you know any functional languages? Can you (intelligently) debate Perl vs. Python? Do you know why Fortran can be much faster than C? Do you believe that a virtual machine can be faster than assembler? If you said "no" to any of those, yet refuse to look past your C knowledge, then you're depriving yourself of a lot of good learning.
There's a vast difference between "I haven't gotten around to it yet" and "I've already solidified my way of thought". You seem to take pride in the latter, and for that I feel sorry for you.
Re:Do people still write new C++ code? (Score:1, Insightful)
I've done that before routinely. well, linuxwindows. GCC really is a marvelous thing. The first time I did it by mistake, I was doing part of a data analysis project and couldn't find the binaries, so I just pulled my sources and recompiled it and ran it, only to later remember that I usually ran that part of the analysis on the linux side.
Problem is that as soon as you need windowing or threading, Java is easier to get working than C++, so I do use Java for those. But otherwise I stick with C++.
It loads faster (the OS and libraries are all loaded, and linking in DLLs is so efficient it puts loading a VM to shame), it runs faster (I've checked a few times when I implemnted in both), it leaves me free to pull off nasty tricks if I need a performance boost, it saves memory I can use for my data, the STL and friends are better than in Java, and multiple other things that makes me prefer it.
Obviously my experience comes from data-processing applications (data mining and such). If you're building web applets or small games or other things, your preferences might vary.
Re:C++ is pretty freakin' ugly... (Score:3, Insightful)
One can use function overloading, operator overloading, classes, templates, multiple-inheritance, when one wants to. Each single of them. But one doesn't have to.
Yes, all those things can make your code more complicated, but they can also make your code easier. The question is, whose fault is it, when the first happens?
It is all a matter of me making a (hopefully) intelligent and educated decision at each point in the code. And if sensible, one can even write vanilla C89 in some segments. But one isn't forced to.
> But it also has some incredibly ugly areas as well, add-ons stuck to the side with duct tape and oatmeal.
Yes, the syntax is quite ugly. And it shows that it was more of a bastardisation of C than a clean new language. Still, duct-tape is quite handy. And I prefer duct-tape over the following:
- Sticking to pure C and realise polymorphy by reimplementing C++ via my own object system in C with function-pointers and structs and heavy casting for collections.
- Scrapping C altogether and go for a clean new object oriented language, like C#, which, say, doesn't allow me to modify my pointer the way I want, because I might hurt myself.
> [...] HomerMobile can be more painful than driving a Civic.
Actually, no. To stay with your analogy: Neither C, nor C++ are fully built cars. They are more like kits. And who is to blame when you built a HomerMobile of the latter?
Re:Do people still write new C++ code? (Score:1, Insightful)
In C, the compiler cannot assume that the return of getpid() will not change, so it is called each time. You cannot avoid system call overhad, just avoid making system calls unneccesarily.
In C, you can simply call getpid() once, and keep the result to get the same effect as the VM has. Try it with a system call that cannot be cached, like read()ing a byte at a time from a file descriptor of "/dev/urandom".