Boost logo

Boost :

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2002-01-05 08:57:31


From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
>
> > My second point was that a design with orthogonal policies is simplest and
> > should be strived for. If SmartPtr needs interacting policies, there has
> to
> > be a strong practical argument in favor of that. Until now, the current
> > design of SmartPtr has proven considerably flexible - there's no smart
> > pointer implementation that me or other users needed that couldn't be
> > implemented within the existing framework.
>
> The use of orthogonal policies certainly has a conceptual cleanliness which
> I favor. On the other hand, breaking things up into tiny pieces also gives
> users more details to worry about, so it isn't clear to me which approach is
> actually simplest for users.

What you want is to separate the way the smart pointer is implemented from the
way in which the user specifies a smart pointer configuration. This is all
conceptually explained and demonstrated in C&E. In other words:

  Specification in a Configuration DSL -> Generator/Translator -> Finished
Component Configuration

When you separate the way the user specifies the configuration, it really
doesn't matter, from the users perspective, that the implementation is broken
into dozens of tiny components. You can also have multiple generators for the
same set of implementation components.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk