On 7/17/2020 3:22 PM, Matthew Woehlke wrote:
>
> That said... the trade-offs of a non-thread-safe reference counter
> pointer are obvious. What I'm *not* seeing is a significant value in
> being able to release the object in the callee, rather than when the
> callee returns. This seems like a questionable improvement for the added
> complexity.

That's fair. I'm using it myself so that I can refactor my code in ways
that change the ownership semantics, and write classes that can refer to
objects but may or may not own them, without refactoring to alternate
between std::unique_ptr and & as ownership changes, and without the
overhead of an atomic refcount.

I imagine that it could be used in high-performance settings where it's
important to free resources as early as possible during heavy
computation, but a guess is not a use case.

>
> Anyway, it seems that you could accomplish the same thing with a
> non-thread-safe shared_ptr, and your proposal would be much easier to
> understand if you simply presented it as such.
>

That's definitely a good way to present it. I would add that a refcount
is only needed if it's not known statically what the last use of the
resource is. In single-threaded code, that's always the last occurrence
of the lvalue.