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
> 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
> a much higher testing burden on the library writer. This is mostly due
> the fact that generative designs tend toward a single monolithic
> (or component generator) which manages all the complexity behind its
> 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, gregod at, cpdaniel at, john at