[smart_ptr] sharable_ptr any interest

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[smart_ptr] sharable_ptr any interest

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: [smart_ptr] sharable_ptr any interest

Boost - Dev mailing list
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, <[hidden email]>
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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost