Boost logo

Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2005-03-05 18:03:03


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk