$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.