Re: [boost] Design of a compatible policy-based template

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-25 15:28:54

Mathias Gaunard wrote:
> 
> How do people feel about types with lots of policies?

To my mind, a policy should be extracted to the template parameter only 
when its difference makes the instantiated types not compatible with 
each other. From this point of view the allocators should not be present 
in template parameters of strings or containers, since they don't alter 
the main function of these components.

On the other hand, trying to support these policies in runtime will 
always give a performance overhead. Whether it is significant is a 
case-by-case decision, but in most times it is not. In return you get a 
more constrained and stable set of types and runtime flexibility. I tend 
to think it overweights the drawbacks.

 > How could those
 > issues be addressed, for example in the case of a string type, where
 > there is quite some demand for policies?

If such policies are already present in the template parameters list, I 
try to provide templated operations and functions that may work 
regardless from the policies you are not interested in. This may lead to 
some code bloat, so I often try to go down to some fundamental types for 
internal processings. For example:

// This is actual foo implementation. It may be defined in some
// cpp and explicitly instantiated on a relatively short list of types.
template< typename CharT >
void foo_internal(
   const CharT* begin1, const CharT* end1,
   const CharT* begin2, const CharT* end2);

template<
   typename CharT,
   typename TraitsT1,
   typename TraitsT2,
   typename AllocT1,
   typename AllocT2
 >
void foo(
   std::basic_string< CharT, TraitsT1, AllocT1 > const& s1,
   std::basic_string< CharT, TraitsT2, AllocT2 > const& s2)
{
   foo_internal(&*s1.begin(), &*s1.end(), &*s2.begin(), &*s2.end());
}

If the case is that you are developing a new component, the solution 
similar to shared_ptr is a good one. Especially, if you are able to get 
rid of the dynamic allocation (which I, personally, paranoidly avoid :) ).