How does shared_ptr know which destructor to use?

Question

I wrote the following code to see how a shared_ptr<void> would behave when it is the last reference to a shared_ptr<Thing> and is itself destroyed.

#include <iostream>
#include <string>
#include <memory>

using namespace std;

struct Thing{
    ~Thing(){
        cout<<"Destroyed\n";
    }
    int data;
};

int main(){
    {
        shared_ptr<void> voidPtr;
        {
            shared_ptr<Thing> thingPtr = make_shared<Thing>();
            voidPtr = thingPtr;
        }
        cout<<"thingPtr is dead\n";
    }
    cout<<"voidPtr is dead\n";
    return 0;
}

Which outputs:

thingPtr is dead
Destroyed
voidPtr is dead

It behaves in a way I like, but it's totally unexpected and I'd like to understand what's going on here. The initial shared pointer no longer exists, it's just a shared_ptr<void> in the end. So I would expect this shared pointer to act like it's holding a void* and have no idea about Thing::~Thing(), yet it calls it. This is by design, right? How is the void shared pointer accomplishing this?

I could imagine that the original deleter of the `shared_ptr` is preserved when copying. — πάντα ῥεῖ, Aug 04 '19 at 07:29
@πάνταῥεῖ Obviously a deleter is never stored in any shared ptr instance (be it `std::shared_ptr` or any "owning" smart ptr with sharing); it's dynamically allocated. — curiousguy, Aug 05 '19 at 06:44

score 33 · Accepted Answer · answered Aug 04 '19 at 07:28

The shared state co-owned by shared pointers also contains a deleter, a function like object that is fed the managed object at the end of its lifetime in order to release it. We can even specify our own deleter by using the appropriate constructor. How the deleter is stored, as well as any type erasure it undergoes is an implementation detail. But suffice it to say that the shared state contains a function that knows exactly how to free the owned resource.

Now, when we create an object of a concrete type with make_shared<Thing>() and don't provide a deleter, the shared state is set to hold some default deleter that can free a Thing. The implementation can generate one from the template argument alone. And since its stored as part of the shared state, it doesn't depend on the type T of any shared_pointer<T> that may be sharing ownership of the state. It will always know how to free the Thing.

So even when we make voidPtr the only remaining pointer, the deleter remains unchanged, and still knows how to free a Thing. Which is what it does when the voidPtr goes out of scope.

Deduplicator · Answer 2 · 2019-08-04T23:55:41.657

The shared_ptr only knows how to handle a management-object with a known interface. That management-object provides two reference-counts (weak for itself, strong for the managed object), as well as containing the deleter (access aside from calling it is only provided if the type is known) and pointer to be deleted (private).

What type and object the shared_ptr points to is a completely separate concern from the management-object it uses, though for sanity it should not be longer-lived.

How does shared_ptr know which destructor to use?

2 Answers2