Pavel Vozenilek wrote:
"Peter Simons" wrote:
Others have expressed (perhaps not publicly) that their preferred method would be that secondary destructions are simply no-ops, rather than being errors or asserting at all. Such conflicting interests make it seem like a policy is indeed necessary.
Well, having a policy mechanism won't hurt. I'm all for it. ;-)
Adding one more policy reduces number of people who will use a template. This is equivalent of adding one more parameter to a function and seeing people writing their own homemade version.
/Pavel
Except that I plan to use a different policy mechanism with the new version, so that client code need only concern itself with relevant policies. Client code will be able to specialize specific policies for a given category, and then just choose a category for each singleton, like so: struct MySingletonCategory; // must provide specializations in singleton namespace namespace boost { namespace singleton { // the following specifies that multi threading will be used for singletons which use MySingletonCategory template < > struct threading_policy < MySingletonCategory > { typedef multi_threaded type; }; // no other specializations provided, so defaults for other policies are used automatically // now tie our specific singleton type to this category template < > struct category < MySingletonType > { typedef MySingletonCategory type; }; } } // close namespace void test ( ) { singleton_ptr < MySingletonType > ptr; // no policies are specified here } Granted, defining a category like so is a bit more work, but client code can completely ignore policies that it doesn't care about, and reuse useful categories that it has defined for multiple different singleton types. Perhaps macros could be used to make this a cleaner process for client code. With this model, introducing many policies shouldn't cause any problems, and policies can even be added retroactively without breaking existing code. -Jason