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 :) ).