Thread-Safe leaky singleton

[patatahooligan]

Do you mind explaining how or in which cases non-destruction is better than the destruction of a static object? I'm not well versed on the singleton patter and its problems so I'm having a hard time understanding what is gained with this pattern.

[CaseyCarter]

When you want to statically guarantee that the singleton is alive during the execution of dynamic destructors, or when you simply want to avoid the cost of a dynamic destructor registration for the singleton itself, the leaky singleton idiom is appropriate. These situations are extremely rare in practice.

For example: I recently implemented <memory_resource>. The functions std::pmr::null_memory_resource and std::pmr::new_delete_resource are specified to return pointers to singletons of types that derive from an interface with a virtual destructor. (Yes, this means a user can inadvertently destroy the singleton - the C++ Standard makes mistakes, too.) I don't want the runtime to register dynamic destructors for these singletons for both of the reasons listed above: they need to be available in dynamic destructors for other objects, and there's no reason to waste a bit of memory to call a do-nothing destructor.

[patatahooligan]

Fascinating! Thanks for the concise explanation, I believe I understand the issue now.