On Thu, Feb 13, 2025 at 3:24 PM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> This is not a good proposal for 2 reasons.
>
> 1. You would need to make unique_ptr more complex in order to support the
> notification mechanism to the non-owning pointer. Which goes against the
> philosophy of not paying for what you don't use. And this would penalize
> current developers who use unique_ptr, and don't use this feature and don't
> want to pay for it.
>
> But this problem can be mitigated by creating a new "complex_unique_ptr"
> type.
>

I think you might have misunderstood the proposal. The author isn't
proposing to change any interfaces or implementation of `std::unique_ptr`.
They're proposing that *individual `std::unique_ptr` instances* can be
declared in a way to make them compatible with this idea.

Note that they linked to a working implementation that neither requires nor
makes any such changes. Here's the relevant section
<https://github.com/make-cpp-nice/ptr_to_unique?tab=readme-ov-file#classes> of
the README.

Cheers,
Chip


> 2. In a post multi-threaded world this is a bad idea that simply wouldn't
> work. You need to take in consideration code context, ownership and life
> times of objects.
> If the life time of the smart pointer is guaranteed in the current
> execution context you simply don't need an extra smart pointer, a reference
> to the original unique_ptr would do, or even a the actual raw pointer.
> If you can't guarantee the life time, because your new pointer is not an
> owning pointer, even if you validate before use, by the time you actually
> use the object could already have been deleted leading you to dereference a
> dangling pointer.
> This model doesn't work.
>
> What you are looking for is a shared_ptr and a weak_ptr.
> A weak_ptr works because the process of validation is to acquire a
> shared_ptr in the current context, which guarantees that by the time you
> use the pointer is not dangling because you have a shared_ptr that prevents
> it from being destroyed.
>
>
>
>
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Thursday, February 13, 2025 8:37:59 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* JOHN MORRISON <inglesflamenco_at_[hidden]>
> *Subject:* [std-proposals] A non-owning but self zeroing smart pointer
> for single ownership
>
> *A non-owning but self zeroing smart pointer for single ownership *
> We need this when we want hold a persistent reference to an object already
> owned by a unique_ptr to use later if it is still valid. Not having it
> leaves us using raw pointers and we don't have a good art of preventing
> them from dangling (knowing if they are still valid). Our mitigations tend
> to be fragile and often break. It is scary enough to deter us from doing
> such a thing but sometimes we have to and it is here that dangling pointers
> remain a huge hazard.
> It doesn't have to be like that, We can have a smart pointer for the role
> but it will be involve intrusion on the owning unique_ptr declaration so it
> can notify deletes and some reference counting overhead but with that it is
> rock solid (valid or null). Here is a working example:
> https://github.com/make-cpp-nice/ptr_to_unique A smart pointer to an
> object already owned by a unique_ptr. It doesn't own the object but it self
> zeroes when the object is deleted so that it can never dangle.
> The addition of something like this to the Standard Library would complete
> safe smart pointer coverage for heap allocated objects. It is the missing
> piece needed to do this. Its safe encapsulation of an idiom that was
> unreasonably hazardous will also open up new design opportunities.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>