Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Practical C++ Programming, Second Edition 266

Posted by timothy from the pretty-good dept.
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.
This discussion has been archived. No new comments can be posted.

Practical C++ Programming, Second Edition More

Practical C++ Programming, Second Edition

Comments Filter:

  • $4 less and free shipping at amazon! (Score:3, Informative)

    by Anonymous Coward on Friday August 22, 2003 @12:31PM (#6766041)
    Amazon has it for $4 less and with free shipping! [amazon.com]

  • Great opening. (Score:4, Funny)

    by stratjakt ( 596332 ) on Friday August 22, 2003 @12:33PM (#6766054) Journal
    Practical C++ Programming is dedicated to teaching the reader how to program in the C++ programming language.

    No shit, I thought it was the next in the Harry Potter series. My kids are going to be disappointed.

    Sorry, it's just that thats the kind of retarded formula-generated opening statement you'd expect from an 8th grader with no interest in the material. Ie; "The Treasure of Pirate Cove is about a treasure in a place called Pirate Cove"

    By the way, I love iPods, so mod me up up up!

    • Re:Great opening. (Score:4, Funny)

      by cK-Gunslinger ( 443452 ) on Friday August 22, 2003 @12:49PM (#6766262) Journal
      Not only that, but "The author encourages the reader to use a computer..."

      Man, talk about "Practical Programming!"

      • You youngins and your fancy schmancy computer thingies. Back in my days we didn't have no fancy "computers" and we were grateful! We all did are programming using pseudocode. We never had to deal with memory or speed restrictions! The sky was the limit! Things have gone downhill since they made the switch to those fancy computers. So show some respect, sonny!

        Yes sir, those were the good ol' days.

    • On thge other hand, whenever a submitter does not begin by saying what the subject is all about here on Slashdot, he/she gets flamed to hell and back for not doing so.

      On the whole, far better to be a little obvious than a little obscure.

  • Debugging (Score:5, Funny)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Friday August 22, 2003 @12:33PM (#6766056) Homepage
    All you need for debugging is print statements everywhere. Always works :)

    Rus

    • Re:Debugging (Score:3, Funny)

      by saddino ( 183491 )
      Even better debugging tool:

      putchar('\007');

    • Re:Debugging (Score:2, Insightful)

      by kruntiform ( 664538 )
      Print statements plus lots of assert statements works even better

    • Re:Debugging (Score:4, Interesting)

      by pclminion ( 145572 ) on Friday August 22, 2003 @12:58PM (#6766364)
      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" :-)

      • Even worse is when you do something like use the same function two times in a printf() line. Sometimes, for some reason, it will print the same results for both functions even if the two have different arguments.

        Someone told me it was due to the memory addresses and caching or something. I haven't been able to duplicate it except by accident. :)

      • Re:Debugging (Score:3, Informative)

        by cK-Gunslinger ( 443452 )
        It's not always a memory error. On fast, multi-threaded apps, it is sometimes timing related. That little bit of time it takes to dump some text out to console is often just enough to mask any synchronization problems.
        • The standard way to debug anything is to trace execution and to reveal the program state at points along that trace. A debugger with watches, breakpoints, and variable evaluation is perhaps a runtime counterpart to the edit-compile-execute cycles of printf() statements, so apart from the quickness of the debugger, I don't see what is so different with printf(). The debugger is so supposed to be more inobtrusive (printf() masking a bug by shifting stuff around in time or in memory space), but I am hardpres

          • Visual C++ (and I believe Borland's C++ Builder post v4) support debugging across libraries and processes. Just start your EXE and make sure all the DLLs have debug information, and you can happily put breakpoints into them, step into them, etc. Also works for out-of-process components, although the best there is to run the component in a separate IDE/debugger session.

          • "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.

      • Re:Debugging (Score:3, Insightful)

        by Jeremi ( 14640 )
        Actually it doesn't always work...


        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.

        • But it didn't work the way you expected it to :-) And sometimes (e.g., late at night, early in morning) that makes it harder to infer the real cause.

          On Linux I've had a ton of success using Valgrind [kde.org] to find memory errors. It can identify bad memory reads, writes, uninitialized values, etc. during runtime. Figuring out what is causing those errors is up to you, however. It doesn't substitute for intelligence but it helps narrow the search incredibly.

    • Except when the print routine is serialised and you have a multi-threading bug that only appears under certain conditions, one of them being that all your print statements are disabled :-)

    • Re:Debugging (Score:3, Interesting)

      by cK-Gunslinger ( 443452 )
      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. :-)
    • All you need for debugging is print statements everywhere. Always works :)

      Of course it always works. But since you put print statements everywhere your program probably doesn't do much besides print out the same thing every time you run it ;)

      Actually now that I think about it, your program doesn't even compile. You cannot call a print function without first declaring or defining it, but since you used print statements everywhere you obviously haven't defined it.

      No wait! Since you use print statements

    • Yeah, printf works real great for coding in OpenGL 2.0 Shading Language. [3dlabs.com]
      </sarcasm>
    • You folks may laugh... but he's right! It's the single most versatile, most general, and most widely available method for debugging. I've used it everywhere from my palmtop's built-in language to mainframe COBOL programs, from little Perl scripts to multi-tier Java systems. For anything complex, I find debuggers give either too little information or too much; it's much easier to fine tune print statements to narrow down exactly there the problems are, or at least exactly the information you need to illum

  • Sweet (Score:3, Funny)

    by Karamchand ( 607798 ) on Friday August 22, 2003 @12:34PM (#6766076)
    That's sweet, four goals: 1.) 2.) 3.) 4.) 4.) ;-) Otherwise, good review! Thank you!

  • Obvious, ignore (Score:5, Funny)

    by Anonymous Coward on Friday August 22, 2003 @12:39PM (#6766140)
    1) Write practical C++ programming book 2) Get it published 3) Have it reviewed on Slashdot 4) ??? 4) Profit!!!

  • Teaching the user C++... (Score:5, Informative)

    by devphil ( 51341 ) on Friday August 22, 2003 @12:39PM (#6766143) Homepage


    ...should, I have decided, always involve the text Accelerated C++, by Koenig and Moo. They have been working with C++ since its inception, down the hall from Stroustrup.

    The book takes two relatively new approaches to teaching C++: 1) don't teach C first, and 2) assume that the standard C++ library is there. So, they introduce "Hello, World" using std::string and std::cout, and they keep using std::string without trying to first teach template classes with default template parameters. The resulting intro programs are very clean and simple, easy to follow.

    The word "pointer" isn't even mentioned until chapter 9. By that point, they're using strings and vectors to solve useful programs, and since both of those containers manage memory themselves, the user needs to know nothing about dynamic memory management (and thus, pointers) before doing the exercises.

    Pointers and user-defined types are introduced, of course, but they don't need to be introduced before showing the reader how to use the basic library features. You don't need to know how an internal combustion engine works before learning how to drive, although going back later and learning what's under the hood will always reward the observant driver.

    This approach has gotten rave reviews, and from actual C++ people, not just fluff reviewers. It's the produce of years of teaching C++ courses.

    Final note: the book is one of the fantastic "C++ In-Depth" series, of which Stroustrup is the series editor. All are very high quality. One of the series' rules is that the main body of the book can be no more than 300 pages, so "make your point, make it simple, make it clear" rules the day.

    • they why bother? (Score:3, Insightful)

      by taradfong ( 311185 ) *
      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.

      • Re:they why bother? (Score:3, Insightful)

        by devphil ( 51341 )

        if you're going the 'don't need to understand 'C', pointer-free,

        Bzzzt. Go back and read it again.

        The idea is that you don't have to learn C before learning C++. That you don't have to learn pointers before learning dynamic expansion of storage. You've conveniently forgotten the last bits.

        Nobody ever said anything about not learning these things at all, not learning the entire language. That'd be stupid.

        To me, the STL was like putting lipstick on a garbage can. It may look prettier now but I'

        • Most people who feel like that had a bad experience with the STL, back before it was standardized, before the language itself was changed to make things easier.

          hash_map is still not an official standard. Until it is, STL will remain a joke.

        • Nobody ever said anything about not learning these things at all, not learning the entire language. That'd be stupid.

          In fairness, Accelerated C++ has a lot going for it and does indeed break new ground (after an amazingly long time with an obvious hole in the market, I thought -- shoulda written it myself!) in how C++ is taught. OTOH, I find a lot of the comments about it somewhat annoying. It isn't perfect, far from it.

          Basically, it's too trendy. Sure, it covers lots of STL things, but in practice a

          • The coverage of exceptions -- an equally if not more important topic than templates -- is almost non-existant. That was a great disappointment, [...]

            I disagree that exceptions are more important than templates. Equally important, okay. *grin* (I would point out that exceptions have been done in other languages, while C++'s templates offer things which no other languages' type-parametric features do.) But that's neither here nor there.

            I do agree with you about the lack of exception coverage; that

    • Just need to second devphil's opinion. Accelerated C++ is a very good book, I regularly lend it to my friends so they can pick up C++.
    • Final note: [Accelerated C++] is one of the fantastic "C++ In-Depth" series, of which Stroustrup is the series editor. All are very high quality. One of the series' rules is that the main body of the book can be no more than 300 pages, so "make your point, make it simple, make it clear" rules the day.

      How delightful! The length constraint means, from what I've seen at bookstores, that no book describing C++ itself can be part of the series. IMHO this says something about the language.
      • How delightful! The length constraint means, from what I've seen at bookstores, that no book describing C++ itself can be part of the series.

        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 lo

  • I don't usually bitch about slashdot "reviews" but (Score:5, Funny)

    by captain_craptacular ( 580116 ) on Friday August 22, 2003 @12:44PM (#6766188)
    This was terrible.
    My favorite diagram is Figure 7-1. "Software life cycle," on page 88; I emphasize with the dinosaur.

    Ok, if I own the book, I'm not going to take the time to read this "review". If I don't own the book I obviously have NO FREAKING clue what figure 7-1 looks like! Also, does "Emphasizing with a dinosour" involve time travel and a shitload of highlighters or what? Or does it mean you hire a dinosour to stand next to you for emphasis? I don't get it...
    • He probably meant to type 'empathize', though I agree with your criticism.

      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 ... OK ... so, which was it? Does it do a good job or does it fall short?

    • I think he meant empathize. This is what editors are good at fixing.
    • Ok, if I own the book, I'm not going to take the time to read this "review". If I don't own the book I obviously have NO FREAKING clue what figure 7-1 looks like! Also, does "Emphasizing with a dinosour" involve time travel and a shitload of highlighters or what? Or does it mean you hire a dinosour to stand next to you for emphasis? I don't get it...

      I have Practical C Programming by the same author, and it has a Figure 6-1 "The Software Lifecycle" that also uses a dinosaur to represent the software. I won

  • Secure programming (Score:3, Insightful)

    by Herrieman ( 167396 ) on Friday August 22, 2003 @12:45PM (#6766217) Homepage
    Any new book - and certainly a second edition- on programming (whatever the language) should have a full chapter on security.
    • I disagree. While security is extremely important, it does not belong in a book that is meant to introduce the reader to a language. It would be a great waste of paper and money if every language book talked about security. If you want to learn security then buy a book on security. The author merely knowning the language doesn't mean that they understand security issues enough to inform readers.
      • It depends. Every (beginner's) book on C/C++ needs to cover what a buffer overflow is, what functions have traditionally suffered from them, and some better options. The also need to cover the importance of checking user input to make sure it conforms to whatever you expect. But you're right, it doesn't need to as in-depth as a book completely dedicated to writing secure code.
        • What does user input have to do with C++? C++ is a programming language. You can do things with it like traverse a file structure, poll the registers on some hardware on your PCI bus, figure out the optimal way to use fuel to boost your satellite into a higher orbit or identify a potential missile target. What the hell place does "checking user input" have in a book about a tool that does these thongs? Being able to code CGI routines doesn't make you a programmer. Programmers do a lot more than write code
    • Why? If your program needs some security measures, that's the time to learn them. Not when you're still just getting the hang of printing "Hello world" to a file.

      Grab.
  • Ok, maybe I'm being a bit harsh...but reviews really should be edited a bit more before posting.

    As for me...I'm never going to "emphasize" with a dinosaur...I might "empathize" with one (if I met one in a deplorable condition)...who knows?

    Now to speak about sentence fragments.

    In summary, this review is a good review that really shines in some aspects and falls short in others. With some improvement, it could be a great review. Of course...if you improve anything, it gets better, now doesn't it?

    Ac

  • 1st Edition Lacked (Score:5, Informative)

    by 4of12 ( 97621 ) on Friday August 22, 2003 @12:49PM (#6766257) Homepage Journal

    The author did a very nice job on Practical C Programming.

    But Steve O. shouldn't have let himself be conned into writing the Practical C++ Programming, though. His C bias weighs too heavily and the first edition spent all kinds of time talking about wonderful linked lists with structs just like the C book did.

    If you want to learn C++, my suggestions are:

    • C++ Distilled by Pohl
    • Effective C++ by Scott Meyers
    • More Effective C++ by Scott Meyers
    • The C++ Standard Library by Josuttis
    some other are also good, and of course no guru should be without one of Stroustrup's tomes.
    • The Meyers and Josuttis books are of little use to a programmer new to C++ or even new to programming in general. They are books designed to extend your basic knowledge of C++ into something more advanced.

      I am about to start teaching a C++ class to several co-workers. The 2 of us "professors" will use Accelerated C++ and the Dietels' book. I would only recommend your selections to programmers familiar enough with C++ to be dangerous, but need to gain a deeper understanding of the language.

  • The first edition ... (Score:5, Informative)

    by Chromodromic ( 668389 ) on Friday August 22, 2003 @12:49PM (#6766260)
    ... is reviewed here [accu.org], at the 'net's largest C++-oriented book review site [accu.org]. This review is decidedly in the negative, although Steve Oualline is given a chance to issue a response which is worth reading.

    It seems that the 2nd edition of this book may have brought forward some previous problems. I have the first edition but never liked it, never thought it really achieved it's goals.

    If you're looking for an uncompromisingly amazing first book on C++, please check out Accelerated C++ [acceleratedcpp.com] by Andrew Koenig and Barbara Moo. This is how I learned C++ and, by using the concepts of teaching core language skills alongside library concepts and best practices in OOP, it truly accelerates the process. Amazing.

  • Changes from the first edition ... (Score:3, Funny)

    by Frater 219 ( 1455 ) on Friday August 22, 2003 @12:51PM (#6766277) Journal
    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.

    I remember the first edition of Practical C++ Programming. Readers who wished to get something out of that book should've noticed that it was absolutely necessary to debug the book's programming examples first.

    Errata? 'Er sure smella like it!

  • How comprehensive? (Score:3, Funny)

    by mgs1000 ( 583340 ) on Friday August 22, 2003 @12:55PM (#6766327) Journal
    You forgot to talk about the most important chapter, with the information every C++ programmer needs to know:

    Chapter VII: How to sign up for unemployment benefits.

  • Don't forget (Score:3, Funny)

    by MSG ( 12810 ) on Friday August 22, 2003 @12:55PM (#6766336)
    Goal 4) teaching proper iteration.

  • why bother? (Score:2, Funny)

    by Rumagent ( 86695 )
    When we can steal it all from SCO...
  • I would like to have seen a more detailed and complete explanation of the object-oriented aspects of C++ (including more diagrams).

    Also, the terms instantiation, polymorphism and encapsulation are not used in the book.

    Seem odd to me that a book that is designed to teach C++ would skimp on the object oriented features of C++. I find polymorphism extremely powerful in many situations. For example, I use it often with bison when writing parsers, and for writing cool Zoo example programs where you call a

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

  • Modern C++ Book? (Score:5, Insightful)

    by ignoramus ( 544216 ) on Friday August 22, 2003 @12:58PM (#6766366) Homepage

    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:

    • Everything you can find that has to do with automated memory management (smart pointers and such)
    • The STL. The STL. I know it's a rite of passage, but I'm tired of seeing every newbie struggling with his own linked list implementation
    • Reuse. The Boost [boost.org] library can teach you a lot about this and demonstrate that focusing on your problem is more fun than writing boring code that's been done a million times before
    • Design patterns. At least an introduction, dammit.
    • Generic programming, in general ;)

    Just my $0.02 for potential authors out there.

    • There are a bunch of books that address these areas. Some quick ones off the top of my head:

      Modern C++ Design
      Exceptional C++
      The Standard Template Library
      IOStreams and Locales
      Effective C++

      I could go on. Sadly though, not nearly as many C++ programmers read this kind of stuff as should.
  • Counting four twice still makes it five.

  • Reference Card (Score:4, Informative)

    by nycsubway ( 79012 ) on Friday August 22, 2003 @01:05PM (#6766438) Homepage
    I also recommend a reference card to help people learn C++. When programming in a new language, it is helpful to be able to look up syntax quickly.

    This is a plug for the card, but you can download a PDF of the card for free.
    • void main? No points.

      ? Not part of Standard C++, which has instead.

      The rest of the card doesn't look much better. The reserved words are listed and the card notes that they can't be used as identifiers, but it doesn't mention that there are other reserved identifiers.

      The description of while(x) says that x must be an expression, but for a long long time C++ has allowed a variable declaration at this point, and such use is idiomatic.

      The example of operator overloading is far from ideal: the argument
      • I must say, the card was not designed to be a reference for expert C++ programmers. It was written as an aide for someone learning C++. College students, and programmers who are learning C++ for the first time are the people who will get the most use out of this card.

        My guess is that if someone can identify that an example is less than optimal, than they dont need this card.

        I've managed to cram a lot of information onto this card, more than is taught in some college programming courses. If I were to add m

  • So It Goes (Score:3, Insightful)

    by Lucas Membrane ( 524640 ) on Friday August 22, 2003 @01:07PM (#6766454)
    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.

  • Great advice. (Score:4, Insightful)

    by Kirby ( 19886 ) on Friday August 22, 2003 @01:09PM (#6766477) Homepage
    >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.

    • Re:Great advice. (Score:4, Insightful)

      by e-Motion ( 126926 ) on Friday August 22, 2003 @02:55PM (#6767490)
      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...

      Unfortunately, C++ is complex, and undefined behavior will upset most attempts at experimentation. For example, suppose a beginning C++ programmer wants to change a string's contents so it contains the text "Count is $count" (Perl-ish code). Most of the time they try stuff like:

      int count = ...;
      string s = ...;
      sprintf( &s[0], "Count is %d", count );
      sprintf( (char*)s.c_str(), "Count is %d", count );

      Does that work? Well, maybe, but the code's not guaranteed to work, and it's dangerous. But the problems with the code will not be recognized by the beginner, and therefore experimentation can lead him to assume something is correct even when it is not. The generally accepted answer of

      ostringstream oss;
      oss << "Count is " << count;
      string s = oss.str();

      is not likely to be discovered through experimentation.

      In general, I agree that experimentation is good. C++ just isn't a safe environment and makes trial-and-error programming difficult.

  • What's Cheaper & Where (why just B&N and A (Score:3, Informative)

    by TastyWords ( 640141 ) on Friday August 22, 2003 @01:10PM (#6766482)
    Instead of comparing just B&N vs. Amazon all of the time, why not use the book shopping bots? (Amazon and B&N are not the cheapest books every time you buy a book (they may be in this case (I checked), but in many cases, the others are much cheaper)! The bots search a lot of the book stores and rank the prices (including handling/shipping), present opportunities for discounts, and even point out the ability for finding books which may be out of print but can be purchased used.
    Think of this as a book equivalent to PriceWatch [pricewatch.com]

    (these links were tested in 'preview' mode before posting.

    BookPool [bookpool.com]
    AddAll [addall.com]
    BestBookBuys [www.bestbookbuys]

  • Another One? (Score:3, Interesting)

    by Wiseazz ( 267052 ) on Friday August 22, 2003 @01:19PM (#6766558)
    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.
  • Comment removed based on user account deletion

  • Steve Oulline (Score:2, Interesting)

    by devphaeton ( 695736 )
    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 oppos
    • "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++"


      As a C++ programmer, this doesn't make sense to me. C++ supports both prefix and postfix operators. Any idea what the author was talking about?

      • As a C++ programmer, this doesn't make sense to me. C++ supports both prefix and postfix operators. Any idea what the author was talking about?

        Just the fact that the prefix operators don't require a temp variable; so if you just need the side effect, use prefix.

        BTW, you don't have to do this, but it's just about idomatic for C++.

        BWP
  • 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.

    ...and in the next edition, the book will have the additional goals of 5) Introduce the reader to US Copyright law 6) How to stay out of prison after violating the DMCA and 7) Learn how to pick the best copyright lawyer

  • there are occasional misleading statements that a beginner probably won't recognize as such.

    Even one example would have greatly bolstered the reviewer's argument here.

    When no examples are given, we do not have any idea in what way the author is "misleading," on which topics the author is liable to slip, or how serious the problem is.

  • The reviewer says the examples have lots of errors, and I couldn't agree more. Here's just one example:

    for (bp = mapstart(mp); bp->m_size; bp++) {
    if (bp->m_size >= size) {
    a = bp->m_addr;
    bp->m_addr += size;
    if ((bp->m_size -= size) == 0) {
    do {
    bp++;
    (bp-1)->m_addr = bp->m_addr;
    } while ((((bp-1)->m_size) = (bp->m_size)));
    mapsize(mp)++;
    }

    ASSERT(bp->m_size

    Can you believe that this kind of code could make it in here? It's the kind of thing that developers would call "ugly."

  • no real errors in the book (Score:3, Funny)

    by calethix ( 537786 ) on Friday August 22, 2003 @02:20PM (#6767177) Homepage
    "Second, source code errors and typos appear regularly enough to frustrate an inexperienced reader."

    but earlier you said

    "4) The author encourages the reader to use a computer to enter, run and debug the book's programming examples"

    Everyone that's ever had a programming class knows all of those errors were intentionaly put there to test you. At least that's what my profs always told me when they gave the class buggy code.
  • Some problems with this review:

    1. Where's the basic information about this book? Author, publisher, ISBN, list price, etc. None of these are mentioned in the review (yes, there's a link to B&N, but, c'mon).

    2. Sequencing is an essential aspect of a technical book review. In what order does the author address the topics? Are there many forward references? Does the author march through the topics one at a time or is the subject matter gradually explored, step-wise? A Table of Contents listing (instead of

Slashdot Top Deals

Kleeneness is next to Godelness.

Close