On 3/14/25 00:46, Jennifier Burnett wrote:
> Ok, thank you for clarifying, I can see your issue now with your example and re-reading the paper. The wording does seem to contradict the idea of shared_ptr being relocatable at all. Imagining a more complicated example:
>
> struct foo
> {
> static inline std::shared_ptr<foo>* foo_inst = nullptr;
>
> ~foo()
> {
> if (foo_inst) printf("%p", foo_inst->get());
> }
> };
> void bar()
> {
> std::shared_ptr<foo> a = std::make_shared<foo>();
> std::shared_ptr<foo> b = std::make_shared<foo>();
>
> foo::foo_inst = &b;
> a = std::move(b);
> foo::foo_inst = nullptr;
> }
>
> Based on how shared_ptr's move constructor is specified (shared_ptr(std::move(other)).swap(*this)), this should print a null pointer, because the destruction of a's foo object doesn't happen until after the contents of b have been moved into the temporary object. If you destroy a before doing a move constructor then the foo's destructor is called before the contents of b has been moved, and so a non-null pointer is printed.
>
> It doesn't seem like shared_ptr can in general meet the isomorphism requirements for being relocatable as proposed, at least not in the case where the destructor of the owned object might have side effects.

Yeah, if user code can observe the difference, then a generic type can't
*really* tell if this affects the semantics of the program. I guess you
have to draw the line somewhere?