On 2/24/25 20:39, Thiago Macieira via Std-Proposals wrote:
> On Monday, 24 February 2025 12:16:16 Brasilia Standard Time Jason McKesson via
> Std-Proposals wrote:
>> As such, the non-aesthetic reason to specifically create a
>> `ptr_to_unique` instead of just using `shared/weak_ptr` is
>> performance: the latter involves book-keeping that (presumably) a
>> `ptr_to_unique` implementation could avoid.
>
> It can't.
>
> If you remove the book-keeping, then ptr_to_unique really *is* a pointer to
> std::unique_ptr. We don't need a new class for that; just use the pointer and
> make sure the std::unique_ptr itself doesn't get destroyed or replaced while
> something is pointing to it.
>
> If you want to be able to have the ptr_to_unique be able to survive the
> destruction or replacement of the unique_ptr they referred to, you need the
> ref-counted block containing something that says the pointed object is still
> alive. And THAT is what shared_ptr + weak_ptr do.

Since unique_ptr doesn't use a control block to begin with, there might
be other implementation options. If we don't care about thread safety,
the ptrs_to_unique could form an (intrusive) linked list, and get
individually cleared when the object gets destroyed. This does make
destruction more expensive, but it has the benefit of not requiring a
separate dynamic allocation, which makes the construction of
ptr_to_unique noexcept. It also makes the actual use of the pointer
comparable to using a raw pointer, instead of having to validate the
pointer against the control block first.