Boost logo

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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk