EmptyCrate Software. Travel. Stuff.

I just spent the better part of the day debugging an insidious little bug. It really shouldn't have taken that long... I even had unit tests in place that covered the code in question! Right!?

The fact is, C++ is a complex language and getting every detail right all the time can be hard. In this case I had a simple class with a boost::shared_ptr in it. In the copy constructor I wanted to clone the pointed to object, but needed to keep the pointer for other house keeping reasons.

class MyClass
{
public:
  MyClass(const MyClass &t_other)

In the context of the rest of the Nobody Understands C++ series, I feel like this one is redundant. But it seems like it needs to be said.

C++ is not an object oriented programming language. C++ is a multi-paradigm language that supports most of the major programming paradigms that have been widely accepted.

Specifically, C++ supports:

I was recently at a talk where the speaker was discussing the history of C++. He argued that one problem with C++ was that its design requirements included backward compatibility with C code, and one fallout of this was the requirement to support all previous types of error handling as well as adding exceptions. That is, C++ supports:

1. Returning of error codes.
2. Error handling functions.
3. Exception handling.

It is true that C++ supports all 3 of these mechanisms, as well as some other cruft left behind from C that unnecessarily encumbers the language. The speaker's point on this one particular case, however, is lost to the fact that every language supports the first two.

There has been much discussion over the years about the usefulness of operator overloading in C++ as well as the ability to get it right.

In reality, it's hard to get it wrong as long as you follow the canonical forms of the operators and don't do unexpected things like overloade the + operator to perform a subtraction operation. Also, the types that your overloaded operators work with should be consistent.

In case you find yourself asking where I get the stuff from that I blog about and wondering if I'm just making stuff up; many of the "Nobody Understands C++" articles on this website are inspired by principles found in the book "C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu. The book is a collection of items from previous books that the pair has worked on together. As such, if you do not own any of the previous books this one makes a great addition to your library.

The book covers 101 best practices guidelines for your C++ code. It does not cover things like indentation level and style of comments, the things that we have all come to consider to be part and parcel with a standards document. In fact, it explicitly avoids talking about those things and says that they should be internally consistent within each file. "C++ Coding Standards" covers topics on program design, object lifetime management, namespaces, generic programming (templates) and the standard library.

It is best to avoid using pointers in C++ as much as possible. The use of pointers can lead to confusion of ownership which can directly or indirectly lead to memory leaks. Even if object ownership is well managed simple (and difficult to find) bugs can also lead to memory leaks.

Security Risks

Also, by avoiding the use of pointers we can avoid and sometimes eliminate common security holes such as buffer overruns. See the last example for more information about this.

Examples

Common instances were pointer usage can be avoided: