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 >
const CharT* begin1, const CharT* end1,
const CharT* begin2, const CharT* end2);
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 :) ).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk