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@lists.isocpp.org> on behalf of Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Tuesday, February 25, 2025 12:12 AM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Thiago Macieira <thiago@macieira.org>
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals