John Torjo wrote:
Hi all,
Today starts the formal Fast-Track review of the Boost.Utility/Singleton library. This is a very useful utility, so I'm expecting lots of reviews ;)
Singleton is a useful pattern and a library that makes it easier to create singletons that work properly under all circumstances is also useful. I am using this library slightly modified to fix compiler errors and warnings from the Vault in production code. I have some performance concerns about on demand initialization. In general I initialize and destroy my singletons deterministically early in main and skip the initialized check for every access. Some people have mentioned Meyer's singleton as an option to skip the initialized check but doesn't the compiler generally just insert that same logic for you for function local statics? The thread safety granularity is wrong. I need to be able to create singletons that I know will only be used from one thread of a multi-threaded program without the overhead of synchronization. The ability to explicitly destroy all the singletons is crucial to my environment where destructors for objects with static duration are not called during program shutdown. The proposed Singleton library provides an easy solution for this requirement which works well for me. I see some overlap between Boost.Pool and the proposed Boost.Singleton and if a Singleton library gets accepted into boost I'd like to see Pool use Singleton. I vote to not accept this library at this time because of the thread safety granularity issues. Thanks, Michael Marcin