In my singleton code, I have been using a template template parameter in my lifetimes for the creator[1], so that client code does not need to duplicate writing the type when specifying the creation policy. The drawback to this is that the creators which provide additional policies need to use a nested struct to avoid breaking the template signature that creators are required to have. A perfect example is the bool_creator[2]: template < bool Value > struct bool_creator{ template < typename Type > class creator { // pass Value to Type's ctor in create method }; }; If I wanted to be consistent, I would be tempted to do the same with my lifetime policies, separating the Type template parameter from the rest and having the singleton use a template template parameter for the lifetime. However, I suspect this would just make client code really ugly when it tried to specify the lifetime it wanted to use. In addition, I am willing to bet that a lot of compilers choke on template template parameters. As an alternative, I am thinking of switching the creator policy to a non template template policy. Although this would make client code have to plug the name of their class into the base singleton template yet a third time, I am thinking that in the end it would be more portable and cleaner. Thoughts? -Jason [1] Yes, I made the name change from allocator to creator in my code. The change has not yet been uploaded though, so keep in mind that creators in this message refer to allocators in the current online code, and bool_creator is really bool_alloc at the moment. [2] I'm thinking of dropping bool_creator from the library. Instead of providing it directly, I'll develop it in the documentation as an example custom creator and go on to show how it can be used to implement a zombie singleton. Of course, if you think it should stay in the library let me know, I can be persuaded to keep it.