Slashdot Mirror
Practical C++ Programming, Second Edition
Practical C++ Programming is a fairly large book: 549 pages organized into six parts containing 30 chapters and 5 appendixes. The parts are as follows:
- The Basics
- Simple Programming
- Advanced Types and Classes
- Advanced Programming Concepts
- Other Language Features
- Appendixes.
I must start by saying that I like the book -- I think it has value. There are a number of things I really appreciate about the book. There are also some problems that adversely impact one segment of the book's intended audience (more about those later.)
The book discusses all the essential elements of C++. Areas covered include: Class definition, namespaces, scope definition and resolution, operator and function overloading, object memory allocation (i.e. new and delete,) type casting, exceptions, inheritance, templates (including an introduction to the Standard Template Library,) the Input/Output system (including the C I/O library), and pointers. All language operators are discussed (i.e. relational, assignment, etc.) Also covered are language elements that C++ has in common with C. The other areas of instruction (programming style, software development concepts, programming tools) are intertwined with the primary topic throughout the course of the book.
One of the book's strong points is the author's excellent conversational writing style. It's hard to find books that combine good technical information with clear expository writing (O'Reilly seems to publish most of them.) Practical C++ Programming definitely succeeds in this area. The author frequently references his own experience to reinforce concepts on programming style, design and debugging. I found his anecdotes useful and occasionally humorous. The book also contains small sections of text that serve to warn the reader of pitfalls (these are marked with a bear trap icon) and areas where caution should be exercised (marked with bear paw tracks). Also, some of the source code examples contain intentional bugs, which the author explains at the end of each chapter. Diagrams, tables and source code examples are found on almost every page of the book, and these are used to keep the reader engaged with the textual discourse. My favorite diagram is Figure 7-1. "Software life cycle," on page 88; I emphasize with the dinosaur.
The book contains some interesting programming examples. The chapters on operator overloading and floating-point math contain source code illustrating how to deal with the numeric precision problems that plague all computers and computer languages. The chapter on the Standard Template Library contains a program showing how to create and use objects that manage a simple roster for enrollment and grading of students. The book also contains several examples of linked-lists and trees, for the purpose of teaching the reader how to use pointers, and to also show the reader the power and usefulness of the Standard Template Library.
Now to speak about the book's shortcomings. First, although the book does a good job of covering the important C++ topics of classes, inheritance, and templates, I think it falls a bit short in these areas (especially the coverage of inheritance). Also, the terms instantiation, polymorphism and encapsulation are not used in the book. The book could have provided a bit more insight into object-oriented concepts. Also, these areas of the book are sparsely diagrammed. Second, source code errors and typos appear regularly enough to frustrate an inexperienced reader. I also found a couple of diagrams to be confusing. Third, there are occasional misleading statements that a beginner probably won't recognize as such. Because of these problems, I cannot recommend the book to people with no previous programming experience. I'm surprised that these problems made it into a second edition.
I think that despite these problems, the book has value to experienced programmers who want to learn C++. C programmers in particular will have an easier time dealing with the source code errors. Also, I think that the book can be used by beginning programmers in a classroom environment, providing the instructor understands the book's problems and is prepared to guide students around them. The book should be particularly useful when read in conjunction with a good C++ reference guide.
Practical C++ Programming is an ambitious work in its breadth and depth. It covers more areas of software development than other C++ books. It takes an interesting approach that some readers will appreciate and others may not.
I would like to have seen a more detailed and complete explanation of the object-oriented aspects of C++ (including more diagrams). A table showing all functions for Standard Template Library containers would have been nice (the book does make reference to two STL web sites). Some mention of third-party object libraries (such as Rogue Wave, Qt, etc.) and their uses would have been helpful.
The lack of a detailed explanation of inheritance may not be bad. I'm one of those who believe that heavy reliance on inheritance causes serious maintainability problems. However, I think the book should have covered this topic more fully, so the reader would understand this issue.
In summary, Practical C++ Programming is a good book that really shines in some aspects and falls short in others. With some improvement, it could be a great book.
You can purchase Practical C++ Programming, Second 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.
Practical C++ programming is C.
After programming in C++ extensively for the last 9 years, I've come to the conclusion that it's much better to program in C (or a scripting language). C++ encourages you to avoid solving the problem by trying to introduce abstractions that also don't solve the problem. This lets you pat yourself on the back for how clever your abstractions are, but you end up with longer code and a half assed solution.
C++ has probably set back the computing industry by 10 years.
Any new book - and certainly a second edition- on programming (whatever the language) should have a full chapter on security.
http://blog.astyran.sg
Print statements plus lots of assert statements works even better
Yes, there is value in this, but most of the book is C++ as if it were C plus some new libraries. It works very hard to delay teaching C++
I taught a beginning C++ class that used this book. It has some nice "these are variables, this is memory, see how they interact" sections for the first time programmer. Which should aid the difficult audience of hose with zero programing experience. As a book an C++, I think it does a poor job. Understand as I write this that I learned C from Kernighan and Richie plus one other ? Efficient C Programing, Weiss ? as a second wording of some things, and then learned C++ from Stroustrup, and Lippman.
Practical C++ makes every effort possible to delay even mentioning pointers, classes, and the rest of the ++ part of C++ as long as possible. Some gradual build up is good. This book takes it to a determental extreme. I think Thinking in C++ by Bruce Eckel's would be a better first book. For the experienced developer, Stroustrup every day.
Without debating the whether C++ is the best choice for beginners, I wish new books on the subject would stop rehashing the same old concepts and methods - not everyone is a C programmer trying to transition to C++. There are a lot of areas that merit greater attention and that will get beginners started on the right foot - and messing with raw pointers isn't one of them.
On top of trying to get the basic OO mindset accross (yes instantiation, polymorphism and encapsulation are big words but the concepts are essential and not that difficult to explain), I'd like to see some more modern and useful concepts explored in depth. For instance:
Just my $0.02 for potential authors out there.
Back when O'Reilly had a _Practical_C_ book, but no _Practical_C++_ book, I called them and said that they should do one. They rejected my suggestion without pause, saying that their kind of readers didn't think that C++ was better than a pitcher of warm spit. Then some other author came out with a _Practical_C++_ book (now out of print), which wasn't very practical, since it was muchly about the C++ standard, which wasn't a standard then and had barely started to congeal when the book was written. Hence, when O'Reilly finally realized that their old readers had already been educated far beyond their intelligence and that they needed to broaden their appeal, they came out with _Practical_C++_Programming_. You can't copyright a title, but at least it cuts down on the confusion. Now it's gone multiple editions. It's pretty good, but nothing is worse than being ahead of your time before the world is ready.
>The author encourages the reader to use a computer to enter, run and debug the book's programming examples. I concur with this advice, though it isn't absolutely necessary.
This is something that novice programmers are well advised to listen to. I constantly am asked by junior programmers 'What happens when I do x', where x is something simple, like try to print out an array.
Half the time, the problem can be answered by simply trying it. And the other half of the time, you end up with a better question (I want to print out the values of an array, but print @array didn't work. What's the trick?) (In perl, see 'perldoc -f join'. That's not my point, but I don't want to leave you hanging!)
And even better, learning the value of experimentation makes you a better programmer, and a much more pleasant junior employee. Instead of spending all your time asking a series of questions, you try a whole bunch of things. By actually stopping to think about the problem, which this approach forces you to do, you end up learning a lot more, and sometimes the failed efforts are exactly what you need later. And if you're stumped, you still end up looking smarter, because you at least tried some approaches. And more often than not, it's easier to learn the answer if you've taken the time to struggle with and really learn the problem you're trying to solve, and remember the answer next time.
I think this is one of the unheralded keys to becoming a good professional programmer.
Caveat: This works a lot better in some development environments than others. I do most of my work in perl, which is ideally suited to this rapid prototype approach. In environments with long compile times, it's more tedious. This is thankfully decreasingly true, with faster machines making the hours-long compiles a historical problem, so take advantage of it, learn to experiment, and reap the rewards.
-- Kate
I mean, if you're going the 'don't need to understand 'C', pointer-free, high-level only route, use something interesting and easy to use like Perl, (heaven forbid) VB, Java, or Python.
To me, the STL was like putting lipstick on a garbage can. It may look prettier now but I'm still never going to kiss it. It's still something you have to wrangle, bang around and not look at when you don't have to.
Does it hurt to hear them lying? Was this the only world you had?
He probably meant to type 'empathize', though I agree with your criticism.
... OK ... so, which was it? Does it do a good job or does it fall short?
I was also did a double take with this remark:
First, although the book does a good job of covering the important C++ topics of classes, inheritance, and templates, I think it falls a bit short in these areas (especially the coverage of inheritance).
Um
The little guy just ain't getting it, is he?
This always indicates...
In other words, adding printf()'s and observing the resulting behaviour change allowed you narrow down what was going on and eventually fix the bug. Or to put it another way, the printf() debugging worked. So your "doesn't always work" claim isn't supported by this example.
I don't care if it's 90,000 hectares. That lake was not my doing.
Have you checked out Advanced Linux Programming? That combined with a good book on C++ would probably give you what you're looking for.
This is inaccurate. It's more correct to say that a complete reference for C++ cannot be part of the series. Which implies that the series are supposed to be terse tutorial books, not references.
IMHO this says something about the language.
It says that the language has a lot of features and a large library. It also says that textbook authors often ramble a lot.
"Another problem with a debugger is if your app is split into DLL's: how do you debug into a DLL if that is where it is choking?"
Uh, use Visual C++? All my apps are split into DLLs. When I'm stepping through something in the debugger, I neither notice nor generally care that I've crossed a DLL boundary. (Except when I'm tracking a memory leak, in which case I notice on purpose...) Most of the time I'm setting a breakpoint deep in the guts of some dll and letting the rest just run until it gets there. Seriously, what's suposed to be the problem with debugging into dlls?
Not sure what you mean by running a DLL "stand-alone". Most dlls don't stand alone. the debugger will tell you everyting passed in to a dll function, at which point it shouldn't matter what called it; ocasionally I write a stupid exe to call one function I think is a problem, but just to speed the debug cycle.