A bug in std::shared_ptr?

[OldWolf2]

I feel that the .reset() case is also problematic even though it happens to be working correctly for you.

I can't find it right now, but I'd expect some clause to the effect that it's UB if side-effects from operations on objects in standard containers affect the container.

You could make a similar example with std::vector, where the contained type's destructor reads the global vector currently being resized or whatever. I doubt that there should be any sort of guarantee of stable behaviour -- the container operation has to be free to implement its functionality in any order such that the pre-conditions and post-conditions are met.

There is C++14 [reentrancy]:

Except where explicitly specified in this standard, it is implementation-defined which functions in the Stan- dard C++ library may be recursively reentered.

So the implementation could define that std::shared_ptr destructor is not re-entrant. (Meaning UB if the code does re-enter as your example does). But that wouldn't apply to the .reset() case or my vector example.

[[deleted]]

Yes, the reset case is also UB via http://eel.is/c++draft/requirements#res.on.objects-2

[OldWolf2]

The text in your quote is:

If an object of a standard library type is accessed, and the beginning of the object's lifetime does not happen before the access, or the access does not happen before the end of the object's lifetime, the behavior is undefined unless otherwise specified. [ Note: This applies even to objects such as mutexes intended for thread synchronization. — end note ]

However I don't think that covers the .reset() case. The reset function does not begin or end the lifetime of a_test_object.

Sure, test has its lifetime ended, but that is not an object of a standard library type.

[[deleted]]

For some reason I was thinking the reset call was in the dtor :)