On 17/10/2018 13:22, Peter Dimov wrote:
Gavin Lambert wrote:
Conceptually "is_destroyed" is usually a bad idea. By definition, after the destructor has run the memory is free to get stomped on by other objects and thus you can't rely on is_destroyed to return any particular value. Trying to rely on it is UB.
It would be undefined to access the "is_destroyed" bool if it were a member of the singleton, but it's a function local static in Alexander's code, and it looks OK to me in that formulation. Static bools are never destroyed.
They are if they're in a shared library which is unloaded. :) Technically it's UB to access a global bool after "destruction" (just like any other object) and it could possibly be "destroyed" before the singleton due to unspecified global destruction order. Though you're correct that since bool has a trivial destructor it is *usually* not actually a problem in practice. (AFAIK a compiler is within its rights to zero or otherwise stomp the memory after "destruction", though most probably wouldn't bother, except perhaps as a diagnostic/sanitiser.) It's still a sign of a fundamental lifetime mismatch somewhere, though.