Re: Automagic instantiation of singletons? (Christian Brunschen)
Re: Automagic instantiation of singletons? (Christian Brunschen)
- Subject: Re: Automagic instantiation of singletons? (Christian Brunschen)
- From: Greg Herlihy <email@hidden>
- Date: Tue, 22 Nov 2005 23:14:13 -0800
- Thread-topic: Automagic instantiation of singletons? (Christian Brunschen)
A singleton, like any C++ object, is initialized by its constructor, but
cannot be instantiated by its constructor. A constructor is called to
initialize an instantiated object, so an object must have been instantiated
well before its constructor could ever be invoked. In many C++ programs,
singletons are instantiated at the global scope, but as noted, this
arrangement causes order-of-construction dependency problems.
One of the best places to instantiate a singleton in C++ is as a static
variable within its own (usually class static) accessor function:
Singleton *GetSingleton()
{
static Singleton sSingleton;
return &sSingleton;
}
The advantage of this so-called "Meyers" singleton, is that the Singleton
object is not initialized until the first time GetSingleton() is called. Or
to put it another way: its instantiation occurs no sooner than the
application has need of it. (And in the case that the Singleton is not
needed at all, it is never instantiated).
This technique also solves the order-initialization problem of dependent
singletons. If every Singleton object in a program is a Meyers Singleton
then any Singleton that has a dependency on another, is assured of its
instantiation the first time it tries to retrieve its dependent.
An unlike a program with global singleton declarations - in which the order
of construction is arbitrary, fragile and difficult to ascertain - a
"cascade" of Meyer singleton instantiations is deterministic, robust and far
more apparent.
There are still certain types of problems, such as circular dependencies,
that have to be fixed on their own. But all in all such problems are far
easier to notice in a group of objects instantiated in a specific order,
than a group with an unspecified and potentially variable order of
construction.
As already noted, it is possible to implement a similar model in Objective C
by defining a class method that returns the Singleton object, instantiating
it if necessary. Provided that other dependent singletons follow this model,
there should be no order-of-construction problems. And in fact some
Foundation objects already follow this approach: NSApplication's
sharedApplication is one example.
In terms of effectiveness, there really is no better solution that would
have the same degree of accuracy and robustness as this one. And the more
complicated a program's object model becomes, the more likely the program is
to run into this problem, and by the same token, the harder it will be to
fix it.
Greg
On 11/18/05 7:36 AM, "Theo Vosse" <email@hidden> wrote:
> The common way in C++ for instantiating singletons is
>
> class Singleton
> {
> public:
> Singleton()
> {
> // Instantiation code here
> }
> };
> static Singleton my_singleton_instantiation_dont_touch;
>
> The static variable will cause Singleton::Singleton() to be called
> before main() is executed. You can mix C++ and Objective-C code
> without problems. There are (AFAIK) only problems with this trick
> when loading dynamic libraries in a multi-threaded context.
>
> A more Cocoa-like way of doing it might be to use +initialize, but it
> doesn't seem to be able to do general initializations (as there is no
> guarantee to when it is called other than "before the first message
> to an object of the specific class").
>
> Anyway, the perfect place for doing initializations in a Cocoa
> application is in main(), just before the call to NSApplicationMain().
>
> Theo
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden