Re: [boost] [smart_ptr] sharable_ptr any interest

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.

Some thoughts:

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
a lease.

On Fri, 26 Oct 2018, 05:01 Marc Pawlowsky via Boost, <boost_at_[hidden]>
wrote:

> 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
> https://github.com/marcpawl/smart_ptr/tree/feature/leased_ptr
> with the documentation at
>
> https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr/sharable_ptr.adoc
>
>
> From the documentation:
>
>
> Motivation
>
> 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.
> <
> https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr/sharable_ptr.adoc#analogy
> >
> Analogy
>
> 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
> keys.
>
> ## 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
>
>
> Thanks
> Marc Pawlowsky
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>