singleton template template parameters
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.
Jason Hise wrote:
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.
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?
I suggested you follow policy_ptr and use mpl metafunction classes as policy template parameters. See, for instance, the array storage policy: http://tinyurl.com/6tbhu. It looks like this: template <typename T> class array_storage_ { ... }; struct array_storage { typedef storage_policy_tag policy_category; template <typename T> struct apply { typedef array_storage_<T> type; }; }; Jonathan
Jonathan Turkanis wrote:
I suggested you follow policy_ptr and use mpl metafunction classes as policy template parameters. See, for instance, the array storage policy: http://tinyurl.com/6tbhu.
It looks like this:
template <typename T> class array_storage_ { ... };
struct array_storage { typedef storage_policy_tag policy_category;
template <typename T> struct apply { typedef array_storage_<T> type; }; };
Jonathan
is this essentially the equivalent of the standard allocator's rebind? -Jason
Jason Hise wrote:
Jonathan Turkanis wrote:
I suggested you follow policy_ptr and use mpl metafunction classes as policy template parameters. See, for instance, the array storage policy: http://tinyurl.com/6tbhu.
It looks like this:
template <typename T> class array_storage_ { ... };
struct array_storage { typedef storage_policy_tag policy_category;
template <typename T> struct apply { typedef array_storage_<T> type; }; };
Jonathan
is this essentially the equivalent of the standard allocator's rebind?
The difference is that an allocator is designed *both* to be used by itself and to generate other allocator types. A metafunction class is generally just a type generator. (In the above example there is also some auxilliary machinery to support identifying template arguments by category rather than position.) Jonathan
participants (2)
-
Jason Hise -
Jonathan Turkanis