shared_ptr | minimal shared/unique_ptr implementation | SDK library

Reviewing, adding some missing code bits:

std::shared_ptr can't be copy-initialized from raw pointer, the conversion constructor is marked as explicit.

You can use direct-initialization:

The shared pointer created has a destroy function object (deleter) that has state. In particular it has a copy of the boost shared ptr.

The destruction action does nothing, it is the destruction of deleter that cleans up the boost shared ptr.

There is a problem though:

Does the C++ standard fully specify cleanup of the deleter itself? E.g. it might stay around when only weak references remain? The standard does guarantee a minimum lifetime for the deleter, leaving the possibility that lives longer than that.

Destroying the destruction object is not specified to occur in either the constructor of std::shared_ptr nor the destructor of std::shared_ptr. It would be reasonable to destroy it either after it is called, or when the reference counting block is destroyed - in the second case, we end up with it lasting until the last weak ptr goes away.

From the draft standard:

[Note: It is unspecified whether the pointer remains valid longer than that. This can happen if the implementation doesn’t destroy the deleter until all weak_ptr instances that share ownership with p have been destroyed. — end note]

The possibility to defer destruction of the deleter is clear. So in that case we end up with shared_ptrs that doesn't destruct their element instance when we want it to be called depending on unspecified details of the C++ implementation you run it on. That is a bad idea.

I would personally go with a similar trick based on the aliasing constructor instead. It is just as simple, has no additional overhead, and the semantics are actually correct:

The raw pointer constructor is explicit to prevent you accidentally taking ownership of a pointer. As there is no concern taking ownership of nullptr the constructor taking std::nullptr_t is not marked explicit.

Note that this only applies to nullptr these other assignments of a null pointer might not work (depending on your compiler):

Like this:

{1,2,3} can be multiple things, and make_shared has no possibility of knowing what it is at the time parameter pack is expanded. If you don't want to state the long std::initializer_list{1,2,3} explicitly, the easiest solutions would be: a. shortening the type's name: using ints=std::initializer_list; b. wrapping the call:

You need to ask yourself a question : Why should B not be copyable?

The example you described, with a graph owning one (or probably multiple) vertexes shows the opposite : B should be copyable! What you don't want is two graphs sharing the same vertex instance.

So you can create a copy constructor / clone method for V along those lines :

You may use a shared_ptr with custom deleter that would prevent the object from being destroyed:

The code can be rewritten with const reference to Base as