Subject: Re: [boost] [smart_ptr] sharable_ptr any interest
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-10-26 05:57:12
Certainly useful for debug builds. You'd want all the leasing code removed
for a release build.
The concept of lifetime management is separate to the concept of ownership
and construction method. So a version that tracks lifetime of a
pre-existing object would be useful.
For debugging it might be nice for the lessees to record a stack dump and
timestamp, or at least code positions in the lease register when they take
On Fri, 26 Oct 2018, 05:01 Marc Pawlowsky via Boost, <boost_at_[hidden]>
> 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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk