Date: Tue, 25 Feb 2025 19:41:51 +0000
Hi Thiago,
I wrote:
> 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.
You wrote: No, it's EXACTLY as burdensome as shared_ptr / weak_ptr. It may not allow doing some operations, but the overhead is exactly the same.
The memory footprint is almost as much as shared_ptr – shared_ptr requires a strong count on the control block whereas ptr_to_unique just needs a valid flag. Where ptr_to_unique is less burdensome is that it uses no thread safety mechanisms. ptr_to_unique also has some overheads the shared_ptr doesn't. You can weigh one against the other but 'exactly' means identity and there isn't.
I wrote:
> 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.
You wrote: In other words, it's not a unique_ptr, but something else.
unique_ptr provides for a second template to specify a custom deleter. Making use of that doesn't make it no longer a unique_ptr. You are working within its design spec. It means it is no longer zero overhead but that also is within its design spec. It is a unique_ptr that has some custom operation or object with access to destruction of its pointee.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, February 25, 2025 12:12 AM
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 16:01:01 Brasilia Standard Time JOHN MORRISON via
Std-Proposals wrote:
> 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.
No, it's EXACTLY as burdensome as shared_ptr / weak_ptr. It may not allow
doing some operations, but the overhead is exactly the same.
> 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.
In other words, it's not a unique_ptr, but something else.
> 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.
Except that it's not unique_ptr. It's something else.
I wrote:
> 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.
You wrote: No, it's EXACTLY as burdensome as shared_ptr / weak_ptr. It may not allow doing some operations, but the overhead is exactly the same.
The memory footprint is almost as much as shared_ptr – shared_ptr requires a strong count on the control block whereas ptr_to_unique just needs a valid flag. Where ptr_to_unique is less burdensome is that it uses no thread safety mechanisms. ptr_to_unique also has some overheads the shared_ptr doesn't. You can weigh one against the other but 'exactly' means identity and there isn't.
I wrote:
> 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.
You wrote: In other words, it's not a unique_ptr, but something else.
unique_ptr provides for a second template to specify a custom deleter. Making use of that doesn't make it no longer a unique_ptr. You are working within its design spec. It means it is no longer zero overhead but that also is within its design spec. It is a unique_ptr that has some custom operation or object with access to destruction of its pointee.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, February 25, 2025 12:12 AM
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 16:01:01 Brasilia Standard Time JOHN MORRISON via
Std-Proposals wrote:
> 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.
No, it's EXACTLY as burdensome as shared_ptr / weak_ptr. It may not allow
doing some operations, but the overhead is exactly the same.
> 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.
In other words, it's not a unique_ptr, but something else.
> 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.
Except that it's not unique_ptr. It's something else.
-- 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-25 19:41:54