I mean the idea of defining the singleton type

struct my_singleton : boost::singleton<my_singleton>
{
   ...
   void DoSmth()const;
   ...
};


And the more important now, the possibility to access it:
my_singleton::instance->DoSmth();


I found it extremely useful to be able to overload the operator -> for accessing the singleton members and may be doing smth. meaningful before and after accessing the member, e.g. monitoring.

I was going to write a review, but somehow missed it...

IMO I would like to have this lib in Boost (would give my YES vote).

Controlling the multi-threaded creation handling via BOOST_HAS_THREADS can be nice by default, but should also be possible to finetune it without redefining macros or including singleton headers before this macro was defined.

So I would prefer smth. like this:

#ifdef BOOST_HAS_TREADS
#    define BOOST_SINGLETON_DEFAULT_LOCKING_POLICY               boost::singleton_default_locking
#else
#    define BOOST_SINGLETON_DEFAULT_LOCKING_POLICY               boost::singleton_no_locking
#endif

namespace boost
{
template<class Derived, class LockingPolicy=BOOST_SINGLETON_DEFAULT_LOCKING_POLICY>
struct singleton
{
   ...
};

}


After all I can write:

struct my_singleton : boost::singleton<my_singleton>
{};

Or if I really want to control locking policy:

struct my_singleton : boost::singleton<my_singleton, no_locking>
{};

I would not like using "macro interface" to control the locking policy of the singleton. As well as it is not always so that if my app has threads I need lockable singleton. I agree that might be needed for shared_ptr to make safe locks, since it might be used in some "local" thread somewhere in the app, but if I for sure know that my singlegon will be instantiated in main() before any threads will start running and that it will be a read-only singleton, I don't need locking.



Many thanks,
Ovanes

Tobias,

may be you need some help? I could help you from the middle of february.


With Kind Regards,
Ovanes