Rocking the blogosphere

C++ tips

Under construction

  • Think about using composition before using inheritance
  • Leverage STL and Boost
  • With STL, use iterators to write container-independent code
  • Known the different STL iterator concepts – e.g..: InputIterator, OutputIterator, ForwardIterator, BidirectionalIterator, and RandomAccessIterator.
  • Use iterator_traits to determine the capabilities of iterators and to write template specializations that are efficient.
  • Always catch exceptions by reference to avoid “slicing”
  • #include guards
  • The explicit keyword for 1 argument constructors can prevent confusing automatic conversions
  • The destructor should generally be virtual
  • Use smart pointers and the RAII idiom
  • Use the pimpl (a.k.a.: “dptr” or “Cheshire Cat”) idiom
  • Prefer C++ style casts
  • Prefer use of const to #define

Effective C++ : 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
More Effective C++: 35 New Ways to Improve Your Programs and Designs
Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
More Exceptional C++
C++ Coding Standards : 101 Rules, Guidelines, and Best Practices (C++ in Depth Series)
Thinking in C++, Volume 1: Introduction to Standard C++ (2nd Edition)
Thinking in C++, Vol. 2: Practical Programming, Second Edition
Modern C++ Design: Generic Programming and Design Patterns Applied

Comments

  1. March 14th, 2006 | 1:11 am

    You’re speaking “Scott Meyers” here, so be proud. One caveat:

    “The destructor should generally be virtual”

    I think a better rule is:

    “If any method is virtual, your destructor should be virtual.”

    A non-virtual destructor is fine if you don’t have derived classes. Even if you do have derived classes, so long as noone would reasonably be invoking a delete a pointer to your base class, there isn’t much of a problem. Unless there is a virtual method, not much point in invoking methods on the base class.

  2. Marc
    March 14th, 2006 | 10:48 am

    Sage advice.

    I’d forgotten about this little page. It would be nice to add more stuff to it, but I’m getting rusty with C++… :-)

  3. June 13th, 2006 | 5:46 pm

    What book would you suggest for someone just starting out in C++? I’m looking to start programming a little bit, haha.

  4. June 13th, 2006 | 10:23 pm

    “Thinking in C++” by Bruce Eckel is a pretty nice introductory C++ book.

  5. September 22nd, 2006 | 6:26 am

    For real C++ newbies, I recommend “Accelerated C++” by Andrew Koenig & Barbara Moo

    See its review by ACCU:

    http://accu.org/index.php/book_reviews?url=view.xqy?review=a002212&term=accelerated

    Also, I’d suggest to start learning C++ from books marked as Highly Recommended in ACCU’s review. These reviews are very helpful guidelines and usually made by C++ gurus.

    Cheers

  6. Steven Black
    September 18th, 2008 | 4:54 pm

    Hmm. Given that you are working in C++ and that inheritance is one of the big factors of the language, I would be more forceful than “The destructor should generally be virtual”.

    If you omit the virtual destructor, then you are pretty much damning your class to never be subclassed. By making it virtual, it leaves the possibility open. Of course, if you don’t like reusable code, enjoy making extra hoops for any other developers to jump through, or feel that the (extremely minor) overhead of having a vtable lookup on your class would be a huge performance penalty, then knock yourself out.

    I would rephrase it as “Unless you have a very specific reason as to not make any subclasses, make the destructor virtual.”

  7. May 26th, 2009 | 11:01 pm

    Steven: If you use C++ for a length of time, you start to realize that inheritance is actually quite often not the right thing. Particularly once you start getting in to using templates, you find that even if you *are* using inheritance, there are many scenarios when you won’t ever reasonably have a pointer to the base class.

    Again, not having a virtual destructor doesn’t mean you can’t subclass. It means anyone who “owns” an instance needs to have a pointer to said subclass instead of the base class. You can actually programmatically enforce that to keep things safe if you are really worried.

    While not having a vtable lookup might seem like it provides a trivial performance benefit, vtable lookups have a cost beyond the lookup itself: they make a whole host of optimizations more difficult, more costly, or just plain impractical. Additionally, if you have no other virtual functions, not having a virtual destructor could mean *not having a vtable at all*, which is of HUGE benefit.

    Most importantly though, not having a virtual pointer is a strong signal of the “never intended to be subclassed” variety, and after working with C++ for a while, you learn that that is roughly equivalent to “you have a very specific reason as to not make any subclasses”. ;-)

Leave a reply