Effective C++, Third Edition
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.
Obviously you don't know much about C++, or programming for that matter. C++ is a great language for almost any task. Java needs that crappy VM (I'm not saying Java is bad, it's just not my cup of tea), and .NET... is that even ported to other operating systems yet (maybe the mono project, but I'm not sure how far developed that is)? The point is C++ is fully portable, easy to use for most tasks, and is powerful.
Hell, I still like C over C++, simply because I feel like I'm really in control of whats going on when I write it, and that I feel I have a better understanding of how it's being executed. If you like this new stuff like Java (and I should point out I don't know Java, or do I have any desire to learn it), you're really not in control of what's happening. Some people that write Java don't even know what the heap is, they don't concern themselves with memory management because it's so difficult to free dynamicly allocated memory with Java.
C++ is by no means an anceint or dead language, hell no.
And ANSI C is perhaps the best general purpose programming language out there. The C Programming Language ought to be required reading, if it isn't already.
As for C++, it's C-- as far as I'm concerned. I honestly can't think of a more painful language to program in. Not even BF and Intercal are more painful than C++. And reading three books on C++ haven't helped.
It must be Windows. It needs half a gig of RAM and a hardware-accelerated graphics card just to run Solitaire.
I woke up one day and realised, "Hey, wait a minute! C++ is crap! I'd been using crap for years and calling it ice cream!"
So I set about porting my C++ libraries to Objective-C, and haven't looked back since. In ObjC they are smaller, cleaner, leaner, and meaner.
Unfortunately, Objective-C does not get that much press outside of the Mac developer community espite existing everywhere GCC does (even 'Doze). Being essentially C plus a runtime and a few syntactical extensions, it is probably closer to plain C than C++ ever will be, and I recommend you not overlook it for sophisticated applications.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
By far the best book I've ever seen for beginners, or relative beginners, is Accelerated C++. The authors have been involved in C++ since its inception and have been teaching it ever since as well.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Incidentally, that's also why the OS isn't written in a safe language -- there's no technical reason favoring C/C++ over Java/C# for an OS.
1) OS dependent on VM
2) VM needs OS to load
3) Lather, rinse, repeat
Don't blame me, I didn't vote for either of them!
Nobody with even half a brain actually believes C++ is a good thing.
Oops (no pun intended), I must've lost half my brain while learning C++. There's nothing wrong with OOP when applied correctly to C in the proper situation. There's nothing wrong with C when a procedural approach is better, and in the end, C++ is often just a better C compiler.
My problem is that the book is probably *Meyers doing templates* again. When templates first came out, I was sold on the idea. Years later, it seems that in practice, you have to write ever more code to cover every possible invocation and possible use. Now, it seems to me that templates are more useful to compiler and library writers than in the real programming world.
*Dons hairshirt garment and waits to be burned as a heretic.*
Some Java and .NET implementations compile to bytecodes, others don't.
And the ones that don't still require a runtime. I would actually switch to Java for a lot of things if I could get one that would compile to native code and didn't require anything more than a standard libc.
And as far as the Java device driver, check out...
Except that it doesn't run on my OS. It doesn't run on any of my friends' OS. Heck, it doesn't even run on Sun's OS, and they own Java! JavaOS is like the Lisp Machine: It's a nice concept but no one really uses it.
p.s. Without having to buy the book, and since you seem to be the expert on this, how does JavaOS manage to bootstrap the VM? Does it cheat and use a C/C++ layer on top of Mach?
Don't blame me, I didn't vote for either of them!