On Monday, 24 February 2025 12:43:45 Brasilia Standard Time Sebastian
Wittmeier via Std-Proposals wrote:
> AFAIU:
>
>
> What makes the new smart pointer non-shared is that after checking the
> ptr_to_unique for validity, the code relies on it staying valid, instead of
> promoting it to the equivalent of a shared_ptr.
>
> That only works well, if no called functions, no interrupt and no other
> thread and no callbacks - which some GUI frameworks love to call in
> response to a GUI API call - and no cooperative multitasking scheme (->
> yield) delete the object.

There's value in knowing whether an object was deleted, even if we can't
provide a thread-safe way to ensure it *remains* undestroyed in the next line.
Like in the case of QPointer, there are many situations in which by
construction you can guarantee that if it hasn't been destroyed yet, it won't
be until some later time. For example, you may have locked a mutex that
prevents the destruction from starting.

For that to work, you need something that will clear the tracking classes when
it does get destroyed. In QPointer/QObject case, we can do that because
QObject itself does the clearing. For a generic class, we can't rely on it
doing that; we'd either need that the object be tracked by some special smart
pointer or that the class derive from a specific base to ensure it gets done (à
la enable_shared_from_this).

If it is a special holder, then the proposal must explain the holder can't be
shared_ptr and the tracker weak_ptr.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering