Practical C++ Programming, Second Edition

adrienlamothe writes "Practical C++ Programming is dedicated to teaching the reader how to program in the C++ programming language. The book actually has four goals: 1) Teach the reader C++. 2) Instill good programming style and practice (indeed, the book's subtitle is 'Programming Style Guidelines.') 3) Teach the programmer basic software development concepts. 4) Introduce the reader to debuggers and the make utility. 4) 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." To see how well the book meets its own goals, read on for the rest of Lamothe's review. Practical C++ Programming, Second Edition author Steve Oulline pages 549 publisher O'Reilly & Associates rating 7 reviewer Adrien Lamothe ISBN 0596004192 summary Guide to learning C++ and programming style.

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:

1. The Basics
2. Simple Programming
3. Advanced Types and Classes
4. Advanced Programming Concepts
5. Other Language Features
6. Appendixes.

You will have to read most of the book in order to learn C++, although there are a number of chapters you can avoid if your goal is to learn only the language's mechanics.

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.

Comments

Practically the 1st Post

[Papatoast]

Embracing C# and the CLR with open arms, but sometimes its nice to get back to C++, with ATL, or WTL...but not MFC or COM stuff.

I need an OS to program for

[WebMasterJoe]

If/when I finally learn C++, it's going to have to be with the help of a book that teach C++ for Windows programming, or C++ for Linux programming. I took a data structures class in college and learned about binary trees and pointers and linked lists and all that stuff, but without being able to write a program that I could imagine actually using, I've had little incentive to remember how to overload the ++ operator.

Are there any good programming books that focus on learning to create GUI's and modern applications? Such as, something that addresses modern concepts like internet connections and DVD drives and database connectivity and such. I don't need to relearn the concepts behind OOP (although a quick overview of syntax would be nice), I want to know how programmers use this stuff, what they create vs. what they have access to (like common dialog boxes), and basically the steps between writing a "sort the list of student records" console app and writing a full-blown application (I know the latter takes a lot of time and code, but I don't know what direction to go in, or how programmers organize all the code).

Re:I need an OS to program for

[Jmstuckman]

I had the same problem as you did with Windows GUI programming. The first thing I tried was the GPL'd "FLTK" library -- it acts as a (somewhat platform-independent) buffer between you and the raw Windows GUI code. The real solution for me was learning Java -- the classes for what you want to do (GUI programming, internet, etc) are built into the standard class library, and every Java book will tell you how to do this stuff. (I didn't even need that -- the docs on Sun's website are very good.)

Re:Debugging

[pclminion]

All you need for debugging is print statements everywhere. Always works :)

Actually it doesn't always work. On more than one occassion I've seen a bug stop happening when I put in a print statement. Take the print statement out, bug comes back.

This always indicates some kind of memory error, usually an overflow of a local buffer, or a bug in your pointer arithmetic somewhere. By making the call to printf() you are modifying the contents of the stack (by pushing the function arguments) and this changes conditions in such a way that the bug no longer occurs.

It's called a "Heisenbug" :-)

Re:Debugging

[cK-Gunslinger]

Hehe, I used to belong to that camp, then I began programming on "real" systems. Needless to say, print statements become less than useful when debugging 40+ threads on 16 CPUs, each receiving 100+ messages per second.

Then again, I never really did find *any* debugging method to keep up with this one application, other than artificially slowing time. :-)

Re:C++ bad

[exp(pi*sqrt(163))]

You know, sometimes that abstraction serves a purpose. Consider a library like FADBAD++ that allows you to differentiate C++ functions for use in problems like numerical optimization. I'd like to see you implement that code in C. The C++ solution is shorter, more elegant, easier to maintain and very easy to use. In fact, for numerical work in general, generic programming in C++ is an incredibly powerful tool allowing you to achieve the performance of FORTRAN with the conciseness and readability of normal mathematical notation. Blitz++ is a good example too.

I find that the people who advocate C over C++ have really done nothing but use C++ as a glorified C. Even the people who claim that they are using C++ properly with high falutin' OO methodologies are still writing code that can be transformed into C with a minimum of effort. Code written generically with C++ templates cannot trivially (in a precisely definable sense) be transformed into C code and hence can be used to efficiently solve problems that are a nightmare in C.

Another One?

[Wiseazz]

How many "How to program in C++" books to we need?

More power to 'em, I guess. It just seems to me that the language has been around for awhile, has aged gracefully, and has an entire library's worth of books written for it.

I suppose it's good to update every once in awhile, but this book doesn't seem to have anything new (based on the review). I'll stick to the 4 or 5 I have, thanks.

Re:Another One?

[Anonymous Coward]

I can tell you why. Book publishers - the people publishers, not the business publishers, have to make money. I did some work for one of the largest (at that time). They were allowed to print books for that year and "make the numbers". The president of the division promised his corporate bosses a 20% increase of the year before but made his individual publishers promise a 30% increase. That way, if they fell short of the 30%, they'd hope to have made the 20% and he'd look good.

Now, let's assign a name to a phrase many are familiar with (here's a way to sound smart in the future): The Pareto Principle. The Pareto Principle is the infamous "80/20 rule". In the publishing world (and practically any other business), 80% of the revenue/profits come from the best-selling 20%. The remaining 80% of the goods produce the remaining 20% of the revenue. The trick is to find the right 20% and make them "right", then find enough other "reasonable" things to sandbag the slack.

On top of all of this, many (if not nearly all) of the people who are inside the actual publishing business do not know the technical world - they don't know a bit from a byte unless they're familiar with it from being around the books all of the time. This is not a slam on them - they're editors, not programmers.

Another interesting tidbit about book selections: You will rarely find one book about a topic. If you only find one, it's because it's either: so good every publisher knows they can't touch it so it's not worth the time & effort to try & do so; or, it's so bad it doesn't sell and it's thought the market is so soft it's not worth the resources. If two books appear about a topic and they sell, look out! As soon as you have two, you'll have three, four, etc. It's presumed if the market can support more than one, it can always support one more than what's already there.

Finally, there are books which focus on being "day & date" with a product - their book will be out the day the software product is out - the book may not be good, but it's available such that anyone who buys the product can buy the book. Generally, these books suck, but by the time the decent books come along and displace the sucky books, the publisher of the worthless books have already moved on their schedule to the next day & date books.

Oh, two other issues affecting book qualities: to get a book out on time, there are frequently extra authors, who may (or may not) be mentioned in print. This is to help get the book writing (and into the editors' hands) as quickly as possible. The same goes for editing: If you have a twenty-chapter book, hand two chapters to each of ten editors and tell them to turn it in tomorrow. Tada! It's edited. Another tidbit: editorial staffs of the quicker-paced book publishing firms (usually the day&date types or date-specific books) have an exceptionally high burnout rate so there's constantly a need to train new editors to get them up to speed.

Steve Oulline

[devphaeton]

I don't mean to bag on Steve Oulline. Maybe in person he's a great guy and gets tons of chicks...

But I happen to have his "Practical C Programming", and i discovered after the fact that it gets lots of thumbs down from both comp.lang.c and #c on freenode.

I've also got some personal beefs with it, in that there are many places where it is either implied or specifically stated that C is merely a stepping stone to C++.

"Get into the habit of pre-fixing your increments and decrements (i.e. ++i, --i, as opposed to i++ and i--) because it will make your transition easier to C++"

"A lot of the concepts that are involved with structures in C will become relevant when you move up to Object Oriented Programming C++"

"The next logical step for C programmers is to learn C++"

Maybe some of these statements can be benign or true for most, but me personally, i don't want to learn C++. I think the same end result could be sought with C than with C++.

Just MHO.

Karma be damned.

Re:Steve Oulline

[Anonymous Coward]

Postfix ++ isn't really easier, but it is less efficient. It's supposed to return a copy of the previous value, which is hard for the compiler to optimize away. Prefix ++ can simply return a const ref to the object.

Re:C++ bad

[pileated]

You know you really think that most people must have nothing to do. Whenever they get a new tool, whether circular saw, programming language or exotic spice, they just have to use it everywhere. I guess that's partially just human nature: it's fun to experiment with something new. But they must really not have any serious need for it or they'd just use it for what they needed.

In my experience I'd say more than 50% of all tool users use them for fun/kicks, not because they have a pressing task to do with them.

I know this is way off point. I guess I just don't have anything important to do and slashdot is a fun tool............

Re:Speaking of the book's rating on amazon

[revividus]

Deitel and Deitel is an acquired taste, I think. I have used one of their books (the Java one) and it was all right(read: it was better than my actual textbook), so I guess I could agree with you.

On the other hand, if I hadn't read one, just because it's a standard textbook, I would probably avoid it. I have never yet had an assigned textbook that was worth even a quarter what I paid for it. Both my Java textbooks gathered dust while I studied for classes (no pun intended) out of an OReilly book and the aforementioned Deitel and Deitel book.

In summary; I agree that the Deitel's title may be a good recommendation (depending on your learning style) but not because it's a common textbook -- more like in spite of the fact that it's a textbook.

And as far as `Practical C++ programming' goes, I've read parts of it already, and it's been on my `to purchase soon' list before I even read this reveiw. Steve Oualline is a good writer and explains C/C++ clearly and with some humor.

Just my 0010 cents...