$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-01-17 15:11:42
> |- boost::singleton| : can be used to create Singletons with 
> synchronized initialization.
I've just become aware that g++ already provides synchronised 
initialisation of function-scope statics, unless you specify 
-fno-threadsafe-statics, and that if N2444 is accepted this will be the 
required behaviour in C++0x.  With this functionality, there is no need 
for the proposed boost::singleton class since Meyer's singleton suffices:
class MyClass {
   MyClass() {...};
public:
   static MyClass& instance() {
     static MyClass i;
     return i;
   }
};
What do people feel about implementing functionality in a Boost library 
that will soon become unnecessary?  I previously suggested that we 
could have a safe_static<T> template or macro, but I'm now wondering if 
we really want unsafe_static<T> to get the opposite effect!  Neither is 
simple to implement; a macro like this perhaps:
#define UNSAFE_STATIC(T,t)
   // The compiler would add unwanted locking if we just wrote 'static T t'.
   // So we declare uninitialised memory to hold t, and code our own 
initialisation test.
   static char _#t#_buf [sizeof(T)];  // worry about alignment
   static bool _#t#_init = false;
   if (!_#t#_init) {
     new (&_#t#_buf[0]) T;
     _#t#_init = true;
   }
   T& t = *(???_cast<T*>(&_#t#_buf[0]));
Tobias, since I wrote my review I've seen a few others also suggesting 
that you should decouple the thread-safety features (e.g. the 
synchronous access in your mutex_singleton) from the singleton itself.  
I would be interested to know whether you would consider doing this in 
a revision of your submission, or whether you want to stick to your 
existing implementation.
Regards,  Phil.