Date: Mon, 24 Feb 2025 19:01:01 +0000
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.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 7:39 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
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.
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.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 7:39 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
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_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-02-24 19:01:08