Yes, when I wrote:
>but also the value is trivial enough that it doesn't matter when it's destroyed or what it does when it's destroyed"
that precludes the value from having other refcounting pointers that could then create cycles and leak.
>but also the value is trivial enough that it doesn't matter when it's destroyed or what it does when it's destroyed"
that precludes the value from having other refcounting pointers that could then create cycles and leak.
Unless you know you must share objects with multiple potential owners, though, std::unique_ptr is a lot wiser.