How to use smart pointers?

I know that in C++, a smart pointer is a better way to handle pointers: they automatically delete the object when the conditions are met. But the conditions here are a bit complicated. For example, according to https://en.cppreference.com/w/cpp/memory

std::unique_ptr disposes of that object when the unique_ptr goes out of scope or we explicitly delete it. In the first case, what makes it different than just using a normal non-dynamic object (the one we create on stack that will automatically be deleted). For the second case, well, it's not smart anymore when we have to manually delete it

std::shared_ptr is kind of the same

Now my question is, if the smart pointer gets deleted automatically, how can we pass the pointer to another function? The whole point of dynamic memory allocation is to be able to use the object outside of the function after all. Or did I misunderstand the idea of "out of scope"?

Any good documentation on this is appreciated. I haven't seen any good documentation on this subject

> what makes it different than just using a normal non-dynamic object

If you can use a local object rather than a pointer then that's almost always better. However in a lot of cases a local object isn't an option e.g. if you want to create an object polymorphically, if you want the object to have a different lifetime to the scope it's created in etc.

> it's not smart anymore when we have to manually delete it

You have the option to delete it manually, the important smart bit is that it'll be deleted automatically on destruction if you don't delete it manually.

> how can we pass the pointer to another function

You can transfer (unique_ptr) ownership of the pointer by moving it into another location or share ownership (shared_ptr) by copying it into another location. Therefore the lifetime of the pointed to object doesn't have to be the same as the original smart pointer object.

For example:

struct Foo
{
  virtual ~Foo() {}
};

struct IFactory
{
  virtual ~IFactory() {}
  virtual std::unique_ptr<Foo> make_foo() = 0;
};

struct Bar
{
  void setFactory(std::unique_ptr<IFactory>&& factory)
  {
    mFactory = std::move(factory);
  }

  void useFoo()
  {
    std::unique_ptr<Foo> foo = mFactory->make_foo();
    // Do something with foo
    // foo is now automatically destroyed 
  }

  std::unique_ptr<IFactory> mFactory;
};

struct FooImpl : Foo
{};

struct FooFactory : IFactory
{
  std::unique_ptr<Foo> make_foo() override
  {
    return std::make_unique<FooImpl>();
  }
};

int main()
{
  // there's no need for bar to be a pointer so just use a local object
  Bar bar;
  bar.setFactory(std::make_unique<FooFactory>());
  bar.useFoo();
  // the factory is automatically destroyed when bar is destroyed
}

The polymorphic factory is created in main and it's ownership is transferred into the member variable in bar. When invoking the factory it creates objects whose ownership is then transferred to the caller of the factory.

Credit to Josh Cross, the TA for the class

Internally, you can think of a smart pointer as keeping track of how many references of itself there are, and it deletes the object when there are none left. It might look something like this (note this syntax is probably somewhat wrong, but the idea is still the same and that's what I'm going for):

class SmartPointer<T> {
    static unordered_map<T*, unsigned int> counts;
    T* internal_ptr = nullptr;
public:
    // Creating a new smart pointer
    SmartPointer<T>() {
        T* ptr = new T();
        counts[ptr] = 1;
        internal_ptr = ptr;
    }

    // The copy constructor (see below)
    SmartPointer(SmartPointer<T> &other) {
        internal_ptr = other.internal_ptr;
        ++counts[internal_ptr];
    }

    // Destructor, but do we need to delete?
    ~SmartPointer() {
        if (--counts[internal_ptr] == 0) {
            delete internal_ptr;
        }
    }

    // Overloading the dereference operator
    T *operator(void) const {
        return *internal_ptr;
    }
}

Let's unpack this section by section.

Member Variables

First, we have the member variables. One is obviously to keep track of the pointer (internal_ptr), but the other is a bit more interesting. The unordered_map allows us to have something like an array, where the indexes aren't integers, but are pointers, and each points to an unsigned integer. This allows us to keep track of how many smart pointers are pointing to a given object. It is static so that all SmartPointers share the same map (note there is probably a better way to do this, but this is just to show the concept).

Constructor/Destructor

Now, we have two constructors and a destructor. The regular constructor creates the new object (normally it would allow for parameters, but for ease here I'm excluding it) and stores its value internally. Additionally, it sets the count for the number of smart pointers associated with that to 1, since we just created it.

The next constructor is known as the Copy Constructor. This constructor is called whenever we need to copy this object to somewhere else. This includes:

• Setting another variable equal to an already existing smart pointer (SmartPointer ptr2 = ptr1;)
• Passing the smart pointer into a function as a non reference (foo(ptr);)
• Returning the smart pointer from a function (return ptr) (this is technically not always true, but this gets to super specifics that aren't important here so we will just pretend it is here).

In any of these cases, the Copy Constructor will be called with the parameter as the source smart pointer. Thus, we take its internal pointer, since we want the same one, but we also need to increase the count of pointers pointing to it by 1, since there are now too.

We also need the destructor! It will first decrease the number of smart pointers pointing to the internal pointer by 1 (since we are about to be deleted). Then, it checks to see if there are no remaining other pointers, and if so, it will delete the object it is referring to.

Operator

Finally, we have the * operator overloaded, so if we tried to do *ptr (just like with a normal pointer), we get the same dereference we are expecting.

Answering your original question

So, onto your original question! How does it not get deleted when we pass it to another function or etc? Well! In this case, it will still have the original smart pointer, and a copy of it will be created (thus the counts will have 2). It will do whatever it needs to in this function, then return, which causes the parameter to go out of scope and be deallocated. This decreases the count back down to 1, which means it won't be deleted quite yet, since it still has a reference available!

unique vs shared vs weak

I want to add an addendum to this since you weren't totally sure about the difference between the three types of pointers. It's really important to understand it and be able to use them at all, so I wanted to highlight this.

unique

A unique_ptr is a smart pointer that can only have one smart pointer pointing to it. This is actually not a "real" smart pointer, and doesn't do what I described above, because you can only have one of them at a time. It's totally fine to return them and pass them to other functions (it differentiates this versus trying to set it equal to another unique pointer), but you can only have one of them pointing to something, ever. Thus, these aren't really as useful in most situations, because you usually want to use smart pointers when things are complicated, not when there's only ever one reference to something.

shared_ptr

A shared_ptr is what I described above! It uses reference counting to keep track of how many objects are pointing to the pointer and works like I described above... But there's a problem. Let's take our BST as an example.

class Node {
    shared_ptr<Node> parent;
    shared_ptr<Node> left, right;
    ...
}

class BST {
    shared_ptr<Node> root;
    ...
}

int main() {
    BST bst;
    bst.insert(8);
    bst.insert(3);
}

In this example, we have a BST that has two nodes: 8 and 3. The 8 node has a shared_ptr pointing to 3, and the 3 node has a shared_ptr pointing to 8 (as its parent). Additionally, the BST has a pointer to 8, as it is the root. But what happens when bst goes out of scope? Well, the number of shared_ptrs pointing to 8 goes from 2 to 1 and... Uh oh. Nothing gets deleted, because we have a circular reference chain here.

So are shared pointers utterly useless? Or is there hope yet (spoiler, there is)?

weak_ptr

A weak_ptr solves the above problem! A weak pointer is like a shared pointer, in that it keeps track of the pointer internally, but unlike the shared pointers, it does not contribute to the counts for the pointer. This means that we can basically have an extra pointer that "doesn't count", and only exists for us to traverse around. So, we can fix the code like this:

class Node {
    weak_ptr<Node> parent;
    shared_ptr<Node> left, right;
    ...
}

Now, things are a bit different! We will no longer have the parent pointer contributing to the number of references that still exist. This means that in the former example, we would have one pointer to the 8 node (the root), one pointer to the 3 node (8's left child), and one weak/non-counting pointer to 8 (3's parent).

So, when the BST goes out of scope, the number of pointers pointing to the 8 node will be... Zero! So it will be automatically deallocated! Which makes the number of pointers pointing tot he 3 node also be zero! So it will be deleted, and so on and so forth for the entire tree.

With a setup like this, you do not need an explicit destructor for the BST or Nodes! Everything is taken care of behind the scenes for you.

Thus, a mixture of weak_ptrs and shared_ptrs is required when you have any sort of circular referencing, and this can often make it hard (or impossible) to use them in certain situations, unfortunately.