ptr_to_unique does use a control block. It isn't as burdensome as that of shared_ptr/weak_ptr but it is more than half way there. It also requires the unique_ptr it works with to be fattened by a notifying mechanism (custom deleter) that holds a pointer to
the control block.
Performance isn't the motivation. The motivation is to have something that works with unique_ptr because single ownership is often a requirement in a model and I want to hold long term references to items within that model that test as null when they are no
longer valid.
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel DCAI Platform & System Engineering
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals