For what it's worth I faced the issue of singletons in the serialization library. I wanted a system which didn't require dragging in a multi-threaded library but I also wanted a system which would be thread-safe. I looked around quite a bit. Just at that time, a singleton library was accepted for review.
From what I remember it was much more complete, documentation, examples, addressing of thread issues etc. I resolved to wait to see if that library was accepted. It was not accepted.
I made a singleton library along the lines of that being suggested here. That library can be found in the documentation for the serialization library. The implemenation is a template which generates a singleton from any given class. It has two accessor functions: T & get_instance() and const T & get_const_instance() My ideas was that if one wanted in add thread locking somewhere it could well be in the class T. In any case, since all my usages were constructed before main is called and then there was no locking required. (I tweaked the library to achieve this). So this worked well for me. Header only and very useful. But for one fly in the ointment. If a singleton is used inside a DLL, the constructor is invoked when the dll is loaded. If the DLL is loaded explicitly with something like "LoadDLL" from multiple threads then it would be a problem. Also, the "singleton" aspect is local to the execution module. That is, if the singleton is used in both the DLL and the main module there are two "singletons" created - so they're really not singletons any more. Maybe they have to be called "moduletons". Anyway just wanted to illustrate their is a lot of history/bagage/whatever associated with this topic and it's not going to be easy to reach a concensus on something like this. Robert Ramey