Re: understanding singleton design pattern
On Jan 18, 8:03 pm, Rolf Magnus <ramag...@t-online.de> wrote:
Marcel M=FCller wrote:
Instead of the singleton design pattern, if the above
function is used, what are the drawbacks of using the above
function ? What are the advantages of singleton design
pattern over the above function ?
The constructor of Test must be public for the above to
work. So the compiler would not reject, when a second
instance of Test is created. It is only up to the programmer
whether to use Test as a singleton or not. Of course
alternatively you could make getTestInstance a friend of
Test. But making it a static member of Test is more clear.
Furthermore if the application should provide a defined
behaviour at shutdown, you must delete Test somewhere.
static boost::scoped_ptr<Test> instance;
will do this job for you. If you do not have boost,
std::auto_ptr is fine too.
In that case, there is no point (no pun intended) in using a
pointer. You can simply create an instance directly. However,
both have another issue. See entries about "static
initialization order fiasco" in the FAQ.
The lazy initialization should solve the order of initialization
problem, at least in a single threaded environment. (In a
multithreaded environment, the simplest solution is guarantee
that the function is called at least once before threading
starts.)
With regards to other issues:
-- You normally *don't* want the destructor of a singleton to
called; calling it can introduce order of destruction
issues.
-- If you do need destruction, using a local static is a better
solution than any smart pointer.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34