On 2/25/25 01:20, Thiago Macieira via Std-Proposals wrote:
> On Monday, 24 February 2025 17:21:43 Brasilia Standard Time Ell via Std-
> Proposals wrote:
>> If we don't care about thread safety,
>> the ptrs_to_unique could form an (intrusive) linked list, and get
>> individually cleared when the object gets destroyed. This does make
>> destruction more expensive, but it has the benefit of not requiring a
>> separate dynamic allocation, which makes the construction of
>> ptr_to_unique noexcept. It also makes the actual use of the pointer
>> comparable to using a raw pointer, instead of having to validate the
>> pointer against the control block first.
>
> The destruction must be more expensive because there's non-zero amount of
> extra work to happen. There's no escaping that.
>
> I think I understand this linked list solution. The observable_ptr class
> contains two pointers: one to the object and one to the list, initially set to
> null. Each ptr_to_unique that gets added simply inserts into the head of the
> list, so it's noexcept and O(1). Removal from the list requires finding the
> item, so it's O(n). Destruction of the object must iterate through all
> entries, so it's also O(n).

I was thinking of a doubly-linked list, so that removal from the list is
O(1). This way the overall complexity of managing n pointers is still
O(n), or amortized O(1) per pointer. It's just that the destruction of
the object also becomes O(n).

It's hard to say without a specific use case, but I'd imagine that in
most situations you don't have that many observers per object, so it
makes sense to optimize for access through the observing pointers,
rather than for object destruction.

>
> I would much rather have the observable_ptr class allocate the extra block and
> add a ref-count. The creation of the object is usually already not noexcept,
> so it wouldn't be adding an extra requirement. However, all the operations
> above are O(1). And as a bonus, it's also thread-safe.

You're right that if you're allocating the object you're already in
no-noexcept territory. In the OP's implementation, the ref-count block
is allocated on demand the first time you create a ptr_to_unique. I find
it at least a little surprising that this could throw. Regardless,
avoiding the extra block still cuts down on the number of allocations.

Going on a bit of a tangent -- I don't want to broaden the scope of the
original proposal -- but since the observing pointers don't themselves
participate in the lifetime management of the object (unlike weak_ptr),
I don't see why they have to be tied to unique_ptr, or any other
specific lifetime-management mechanism (for example, you could have an
observable_val<T> value-wrapper that could live wherever). In the
general case, the observed object might not be individually allocated,
which makes individual allocation for the ref-count block even less
desirable.