On Tue, Feb 25, 2025 at 2:41 PM JOHN MORRISON via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

Are those going to actually be meaningful next to the cache pressure
of accessing a disjoint piece of memory? We're not talking about a
mutex lock here; just an atomic operation.

> 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.

It may not be exactly the same, but if the distinction is trivial,
then it doesn't matter. The question is whether there is any benefit
to doing it your way rather than via a `shared/weak` pointer *beyond*
the aesthetics of wanting the ownership to be seen as unique (even
though it 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.

The deleter is intended to deal with the specifics of non-standard
memory allocation. That is, if you have a side heap, memory pool, or
other memory allocation scheme that `delete` doesn't work with, the
custom deleter is there for you.

This design leads to a number of problems for your idea:

1. What happens if someone calls `unique_ptr::release()`? The deleter
is *not* told if the `unique_ptr` gets released. After all, that isn't
the deleter's business. Its job is to deal with destruction and
deallocation, not tracking. By releasing the pointer, the caller is
saying that *they* will handle destruction/deallocation. The deleter
doesn't get to know that this has happened.

2. What would `reset` do? The deleter is told to destroy the previous
object. But because `unique_ptr` does not expect the deleter to be
maintaining state *specific* to that object, it is not told that a new
object is now being adopted. Because again, that's not the deleter's
job.

3. Your deleter would then have to also contain a deleter so that
users can have access to the deleter's actual job: destroy/deallocate.
But it couldn't be just a "deleter" because the user undoubtedly also
wants to have control over the control block's deallocation. And
allocation, for that matter.

Bottom line: you're talking about a new type, not a new deleter.