As mentioned above, the reference counting pointer can be copied. As a result, several copies of a smart pointer could point to the same object. This leads to the question of which copy is responsible for deleting the object that they all point to. The answer is that the last smart pointer of the group to die will delete the object it points to. It’s analogous to the household rule: “the last person to leave the room will switch the lights off.”

To implement this algorithm, the pointers share a counter that keeps track of how many smart pointers refer to the same object—hence the term “reference counting.” Reference counts are used in a wide range of situations: the term simply means that the implementation has a hidden integer variable that serves as a counter. Each time someone creates a new copy of a smart pointer that points to the target object, the implementation increments the counter; when any smart pointer is deleted, the implementation decrements the counter. So the target object will be around as long as it’s needed, but no longer that that.

An implementation of reference counting pointers is provided by my library in the file scpp_refcountptr.hpp. Here’s the public portion of this class:

template < typename T>
class RefCountPtr {
 public:

  explicit RefCountPtr(T* p = NULL) {
    Create(p);
  }

  RefCountPtr(const RefCountPtr<T>& rhs) {
    Copy(rhs);
  }

  RefCountPtr<T>& operator=(const RefCountPtr<T>& rhs) {
    if(ptr_ != rhs.ptr_)
    {
      Kill();
      Copy(rhs);
    }

    return *this;
  }

  RefCountPtr<T>& operator=(T* p) {
    if(ptr_ != p) {
      Kill();
      Create(p);
    }

    return *this;
  }

  ~RefCountPtr() {
    Kill();
  }

  T* Get()const { return ptr_; }

  T* operator->() const {
    SCPP_TEST_ASSERT(ptr_ != NULL,
      "Attempt to use operator -> on NULL pointer.");
    return ptr_;
  }

  T& operator* ()const {
    SCPP_TEST_ASSERT(ptr_ != NULL,
      "Attempt to use operator * on NULL pointer.");
    return *ptr_;
  }

Note that both the copy-constructor and assignment operators are provided, so one could copy these pointers. In this case, both the original pointer and the copied one point to the same object (or to NULL, if the original pointer was NULL). In this sense they behave the same way as the regular “raw” T* pointers. If you no longer need to use the object, you can “kill” the reference counting pointer by assigning NULL to it.

There are a couple of problems with the reference counting pointer. First, creating one with a non-NULL argument is expensive, because the implementation uses the new operator to allocate an integer on heap, a relatively slow operation. Second, of course, the reference counting pointer is not multithread-safe. I’ve declared that discussions of multithreading are beyond the scope of this book, but here it’s important enough to mention. Let’s concentrate on the previous problem—the cost of using a reference counting pointer. You can use it when you are sure that you will need to copy it, and when you can be reasonably sure that the cost of creating one is negligible compared to the execution time of the rest of your code.

In cases when you don’t plan on copying the smart pointer and just want to make sure that the allocated resource will be deallocated properly, as in the earlier examples of the SomeFunction() method, there is a much simpler solution: the scoped pointer. Let’s take a look at its code provided in the file scpp_scopedptr.hpp:

template <typename T>
class ScopedPtr {
 public:

  explicit ScopedPtr(T* p = NULL)
  : ptr_(p)
  {}

  ScopedPtr<T>& operator=(T* p) {
    if(ptr_ != p) {
      delete ptr_;
      ptr_ = p;
    }

    return *this;
  }

  ~ScopedPtr() {
    delete ptr_;
  }

  T* Get() const {
    return ptr_;
  }

  T* operator->() const {
    SCPP_TEST_ASSERT(ptr_ != NULL,
      "Attempt to use operator -> on NULL pointer.");
    return ptr_;
  }

  T& operator* () const {
    SCPP_TEST_ASSERT(ptr_ != NULL,
      "Attempt to use operator * on NULL pointer.");
    return *ptr_;
  }

  // Release ownership of the object to the caller.
  T* Release() {
    T* p = ptr_;
    ptr_ = NULL;
    return p;
  }

 private:
  T*  ptr_;

  // Copy is prohibited:
  ScopedPtr(const ScopedPtr<T>& rhs);
  ScopedPtr<T>& operator=(const ScopedPtr<T>& rhs);
};

Again, the most important property of this class for us is that its destructor deletes the object it points to (if it is not NULL, of course). The difference between usage of the scoped pointer and the reference counter pointer is that the scoped pointer cannot be copied. Both the copy-constructor and assignment operator are declared private, so any attempt to copy this pointer will not compile. This removes the need to count how many copies of the same smart pointer point to the same object—there is always only one, and therefore this pointer does not allocate an int from the heap to count its copies. For this reason, it is as fast as a pointer can be.

You have also probably noticed that in both RefCountPtr and ScopedPtr we diagnose an attempt to dereference the NULL pointer. We’ll talk more about this in the next chapter.

As you’ll recall from Chapter 4 concerning arrays, we have discussed which of the two new operators to use: the one without brackets. As for the corresponding delete operators, we should use neither. Do not delete the objects yourself; leave it to smart pointers.

Now let’s discuss potential errors when using functions that return pointers. Suppose, we have a function that returns a pointer to some type MyClass:

MyClass* MyFactoryClass::Create(const Inputs& inputs);

The very first question about this function is whether the caller of this function is responsible for deleting this object, or is this a pointer to an instance of MyClass that the instance of MyFactoryClass owns? This should of course be documented in a comment in the header file where this function is declared, but the reality of the software world is that it rarely is. But even if the author of the function did provide a comment that the function creates a new object on the heap and the caller is responsible for deleting it, we now find ourselves saying that every time we receive a pointer to an object from a function call, we need to remember to check the comments (or in the absence of a comment—the code itself if available) to find out whether we are responsible for deleting this object. And as we have decided in the Preface, we would prefer to rely on a compiler rather than on a programmer. Therefore, a fool-proof way to enforce the ownership of the object is for the function to return a smart pointer. For example:

RefCountPtr<MyClass> MyFactoryClass::Create(const Inputs& inputs);

Not only does this design leave no doubt about the ownership of the object returned by the function, it leaves no opportunity for a memory leak. On the other hand, if you find the reference counting pointer too slow for your purposes, you might want to return a scoped pointer. But there is one problem: the ScopedPtr<MyClass> cannot be copied, and therefore it cannot be returned in a traditional way:

ScopedPtr<MyClass> MyFactoryClass::Create(const Inputs& inputs) {
  ScopedPTr<MyClass> result(new MyClass(inputs));
  return result; // Won’t compile !
}

Therefore, the way around the problem is to do this:

ScopedPtr<MyClass> result;  // Create an empty scoped pointer
// Fill it:
void MyFactoryClass::Create(const Inputs& inputs, ScopedPtr<MyClass>& result);

Here you create a scoped pointer containing NULL and give it to MyFactoryClass::Create() to fill it up. This approach again leaves no room for mistakes regarding the ownership of the object created by the function. If you are not sure which of the two pointers to return, you can either:

There is also an opposite situation when the SomeClass::Find() method returns a pointer to an object but the user does not have ownership of it:

// Returns a pointer to a result, caller DOES NOT OWN the result.
MyClass* SomeClass::Find(const Inputs& inputs);

In this case, the pointer returned by this function points to an object that belongs to something inside the SomeClass object.

The first problem here is that the SomeClass object thinks that it is responsible for deleting the MyClass instance to which it just returned a pointer, and therefore it will delete it at some point in the future. In this case, if the user of this function will delete the pointer he received, this instance will be deleted more than once, which is not a good idea. Second, this instance might be part of an array of MyClass objects that is created inside, say, a template vector using operator new[] (with brackets), and we are now trying to delete an object from that array using operator delete without brackets. This is also not good. Finally, the instance of MyClass could be created on stack, and should not ever be deleted using operator delete at all.

In this case, any attempt to delete this object that we do not own—directly or by assigning it to a smart pointer of any kind that would take ownership of it—would lead to disaster. An appropriate way of returning this pointer is to return a “semi-smart” pointer that does not own the object it points to. This will be discussed in the next chapter.

Rules for this chapter to avoid memory leaks: