Martin wrote:
Keep at least one global or static pointer to the singleton. The global pointer is different in concept than a real global instance, as it is being used to control the moment of creation, rather than to provide a global point of access. You can hide the global pointer in an unnamed namepace in some obscure source file if you want to make it really clear that it isn't the access mechanism.
The problem is that I don't have a source files to put a global variable in.
My library is a template that lives entierly in header files. At the moment I got a single cpp file that only contains the global variable. It works but it forces the library users to include the source file in their project so I would like to get rid of it.
The singleton seem to solve the problem but since the global variable isn't created until it is used it could happen that two threads create it at the same time. The global variable is constant so it is only the creation that needs locking. I could use a locking policy but it would be easier if I could just force creation at startup.
Well, I guess I don't see any problem with declaring the global pointer in the header... maybe just put it in a detail namespace. An extra pointer will exist in each translation unit, but that shouldn't cause any problems.
Disabling of the singleton's default copy constructor was intentional, you can ignore or disable this warning.
Why does a singleton need a copy contructor?
It doesn't... which is why I disabled it by declaring it privately and not defining it. If I had ignored it a default copy ctor would have been generated. The error is saying that a class deriving from the singleton was unable to generate its own automatic copy constructor because the derived class couldn't access the base's copy constructor, which I had made private and disabled. This is intentional. -Jason