Boost logo

Boost :

From: Tim Woodard (timw_at_[hidden])
Date: 2002-01-23 12:27:19


"David Abrahams" <david.abrahams_at_r...> wrote:
...
> I think things get much trickier with generative programming, where
all of
> the configurations tend to be determined by the library, but there may
be
> thousands of them. The Boost Graph Library's adjacency_list is more
like a
> generative design than a policy-based one, and I think that approach
places
> a much higher testing burden on the library writer. This is mostly due
to
> the fact that generative designs tend toward a single monolithic
component
> (or component generator) which manages all the complexity behind its
facade.
> A policy-based approach breaks the design into smaller pieces which
can be
> verified separately.

One thing I've been working on is applying generative programming as
"front-end" for a policy-based design. In C&E, generative programming
is used in conjunction with the GenVoca architecture. Using it in
conjunction with policies, I think, is more natural. With this
approach, the generator takes user-supplied options and selects
appropriate the policies. Testing the library combinations actually
becomes simpler because the combinations are limited by the generator.
The generator itself can easily be tested by verifying at compile-time
that specified option configurations result in the expected policies
being selected.

Tim Woodard
Diamond Visionics


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