Re: New Singleton Scheme
Gerhard Menzl wrote:
Ema wrote:
class Singleton
{
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
void Init(void) {}
static Singleton& Instance(void)
{
Singleton _s;
return _s;
}
};
int main(int argc, char *argv[])
{
Singleton::Instance().Init();
// now ready for MT use
}
What does Init() achieve which the constructor doesn't?
Simply creates the object in a single thread context (you know if
there are any mutex(es) they get created in a thread safe context).
Init() doesn't create the object.
int main(int argc, char *argv[])
{
Singleton::Instance();
}
would be sufficient.
I personally consider this to be instance of the
<http://en.wikipedia.org/wiki/Sequential_Coupling> anti-pattern. I
don't see how it is really all that different from requiring something
like the following.
void bad_example()
{
Multipleton instance;
instance.init();
instance.do_what_i_mean();
}
However, it is even worse with the Singleton::init case because the code
to initialize the Singleton is not going to be in the same place as the
use of that Singleton, unlike in the above example. Combine this with a
bad case of Singletonitis and you will find a main function with a long
list of singleton initializations, making it difficult to tell whether
or not one has forgotten to initialize one of the Singletons. It seems
to me that the double-checked locking pattern adequately solves the
problems with initializing the singleton instance in a multithreaded
environment and one should only resort to using a different solution iff
this is not an option, e.g. one's compiler does not implement the
volatile keyword in such a way to avoid the potential problems of
statement reordering.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]