The motivation isn't better performance than shared_ptr but I don't want it substantially worse either. It is going to be used to optimize painting routines so they don't cause screen lag. I suspect that setting and testing locks may have more latency and there can be a lockout on the GUI thread if a lock get hit.


As you say, 3 classes would allow threadsafe use:

owning pointer
weak pointer
promoted pointer

But it will place a larger run-time and coding burden on its target single thread use. The adoption of three new smart pointers also looks like a bigger ask. The owning pointer can still be unique_ptr (usurping unique_ptr won't go down well) the delete lock can go in the custom deleter notifier. So it is just two more really. It can be done but I'm not sure it is the way to go. I did think of such a thing many years ago but abandoned it because I couldn't think of a use case that made any sense other than someone doing it by accident.

The main concern with ptr_to_unique is with the consequences of its prohibited use to make cross thread references.
The choices are

1. Document that you shouldn't do it - ptr_to_unique as first presented
2. Make it safe using the delete locking mechanism described above.
3. Take measures to prevent it from happening

I feel that 1. is the cleanest and most straight forward to present. But feel more comfortable with 3.

For my own coding I would be happy with 1
But running a software department I would probably prefer my programmers to use 3.

Unfortunately catching misuse during compilation doesn't seem possible. If it was, 3 would be 1 made perfect.
However, thread checking (one more item on the control block) can be used to catch it in execution and throw. This would be minimally more overhead on correct use and would be enough to stop incorrect use from getting out the door.

Run-time checking for the possibility of dangerous code will probably be viewed dimly. But with the current safety imperative it is perhaps something that should be done more - even if the checks are not always compiled in.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, February 24, 2025 8:18 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership


If performance is not the motivation, why not make it even more similar to shared_ptr, and safer to use?





Why not have 3 classes:



owning pointer

weak pointer

promoted pointer



Only the owning pointer may destruct the object.

The promoted pointer, as long as it is active, delays the destruction.



The owning pointer (or its user) can decide, what to do, if destruction is delayed or not possible (because there are promoted pointers around. Programmatically that should not happen, but here you can define a response instead of getting UB).





You are safe from the case that the pointer is deleted, while you access it.



-----Ursprüngliche Nachricht-----
Von: JOHN MORRISON via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Mo 24.02.2025 20:01
Betreff: Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership
An: std-proposals_at_[hidden];
CC: JOHN MORRISON <inglesflamenco_at_[hidden]>;
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.