Boost logo

Boost :

Subject: [boost] [smart_ptr] sharable_ptr any interest
From: Marc Pawlowsky (marcpawl_at_[hidden])
Date: 2018-10-26 02:57:41

I am working on a idea for a smart pointer called sharable_ptr. A cross
between a unique_ptr and a shared_ptr.

A sharable pointer has a single definite owner like a unique_ptr, and can
be shared to other users similar to shared_ptr as a borrowed_ptr. However
unlike a shared_ptr it is an error if the contents of the sharable_ptr go
out of scope, by destruction or being reset or assigned, if there are still
instances of a borrowed_ptr that reference it.

The work is in its infancy at
with the documentation at

>From the documentation:


sharable_ptr, and its cohorts: sharable_ref, borrowed_ptr, and borrowed_ref are
to help close the raw dangling pointer problem.

Along with unique_ptr and shared_ptr, the number of C++ objects that will
retain a raw pointer can be reduced. It will allow for easier reasoning of
the lifespan of objects, and help catch errors where an object is
referenced after it no longer should be.

Marc owns a cottage on the lake and is willing to share it with his friends
and family. He tells them to drop by anytime they want, even when he is not
there. Amanda uses the cottage on a regular basis. Amanda also lets her
friend Ava use it. Unfortunately due to a change in financial circumstances
Marc has to sell the cottage. At this point neither Marc nor Amanda may use
the cottage any more.

In C++ terms, Marc has a sharable_ptr<Cottage>. When Amanda is at the
cottage she has a borrowed_ptr<Cottage>, which she destroys when she
leaves the cottage. When Amanda lets Ava use the cottage Ava gets a copy of
the borrowed_ptr. Amanda and Ava must destroy their pointers prior to Marc
releasing his.

It would be an error for Amanda or Ava to retain a borrowed_ptr to the
cottage even if she does not use it. Equivalent to retaining a copy of the

## Alternatives

Instead of using `sharable_ptr` and `borrowed_ptr`, you could use

`shared_ptr` and `weak_ptr`. The error detection for a dangling pointer

gets pushed to when the `weak_ptr` is locked to a `shared_ptr`, instead of

when the owned object is freed. A possible advantage is that if the

`weak_ptr` is not used then there is no error. The disadvantage is the
code may have progressed quite a way before it is realized the referenced
object no longer exists.

Is there interest in this idea, should I keep working on it?

I have so far only been working on Mac clang

basement:smart_ptr marcpawl$ clang -v

Apple LLVM version 10.0.0 (clang-1000.10.44.2)

Target: x86_64-apple-darwin17.7.0

Thread model: posix

Marc Pawlowsky

Boost list run by bdawes at, gregod at, cpdaniel at, john at