|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-06-25 14:15:00
> The main problem with a policy-based type, such as a string type with
> many options (flex_string for example), is that different versions of
> the template are different types, and as such are incompatible.
This is a significant issue. A good illustration of the problem is the
Allocator template parameter (call it a policy if you want) in standard
containers. If I want to use custom allocator in my std::vector as part of a
library interface, all user code is required to be templatized. The increase
in physical coupling is not justified.
> An obvious solution would be a type that can hold any of the template
> instantiations, and dispatch the member functions to the appropriate
> type through virtual calls, that could eventually use the stack like
> boost.variant.
Assuming that the additional flexibility you get with policy-based design is
needed -- yes, that would be a solution. Often, a better approach is to
design less flexible interface that better suits the problem domain.
I compare policy-based design to a swiss army knife. If you really have
o -- you don't have a proper knife, or scissors, or whatever -- indeed you
*can* use it for all kinds of things.
> An alternative would be to simply use typedef to choose the type you
> want to use throughout the program, which would somehow give source
> compatibility.
As far as users are concerned, using a typedef is exactly the same as using
distinct types instead of a single policy-based template, except that a
policy-based design would be more restrictive (for the library designer).
Emil Dotchevski
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk