On Tuesday, 25 February 2025 03:07:14 Brasilia Standard Time Ell via Std-
Proposals wrote:
> 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).

Ah, that's a good idea. Each observer knows its node in the list: it is the
node.

Please note that trasversing a linked list (doubly or circular or whatever)
puts more cache pressure on the processor, than a simple array. That's why we
hardly use std::list in C++ and instead prefer to use std::vector everywhere.
C developers would do the same if they had the ability to do templates.

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

Indeed, and you're probably right. But then we have the pathological edge
cases where it's going to be incredibly costly.

And this design locks into something that cannot ever be thread-safe.

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

Unless you create the object and the block in a single allocation. We can call
that function std::make_shared... I mean, std::make_observable.

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

Now this starts to get more interesting because it has further uses that
std::shared_ptr doesn't readily provide for. Though it does provide some.

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