[smart_ptr] sharable_ptr any interest
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/...
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/... 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
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,
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/...
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/...
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
participants (2)
-
Marc Pawlowsky -
Richard Hodges