Boost logo

Boost :

From: timatdvc (timw_at_[hidden])
Date: 2002-02-18 09:26:45

My colleagues and I have been working on some concepts and techniques
that would be useful in developing configurable active libraries. I
wanted to present them here, where many of related ideas have been
discussed before and where these techniques might be most useful.
The main idea is to combine the strengths of policy-based design and
generative programming. Policies allow many possible configurations
of a component, while a generator's goal is to automate the
construction of components based on user-supplied options. In C&E,
they present the GenVoca approach as a possible architectural model.
Policies, we feel, are much provide a more tangible decomposition of
a given problem. Combining these approaches may be able to give the
best of both worlds.

This approach would be applicable for large libraries or components
where the number of policies becomes unwieldy. With a combined
approach, clients specify abstract options using the "grammar" of the
domain/problem space (rather than the implementation/solution space,
where policies sort of live). The generator then uses these options
to select the policies needed to meet the client's requirement.

Here's a bit of code to show how it would look from a user's point of
view. First, a user would construct the list of options that would
be passed to the generator utilizing some typelist mechanism:

// Construct a list of options for the generator
typedef ConstructOptionList<
            SetOptionType <AllocatorOption, std::allocator<int*> >,
            SetOptionValue<OptimizedUseOption, OPTIMIZED_GENERAL>,
            SetOptionValue<OwnershipOption, OWN_REF>

// Provide the options to the generator to make the requested type
typedef LIBRARY_GENERATOR<OptionList>::Type GeneratedLibraryType;

As you can see in this example, rather than have the generator take
many individual template parameters (one for each option), a typelist
is passed that contains all of the selected options. The
LIBRARY_GENERATOR then searches the typelist for each option category
(using some simple metaprogramming, so this happens at compile-
time). If an option category is found the provided type or value is
selected, otherwise the default is used. In this way, any option
default can be overridden in any order, unlike the approaches
outlined in Generative Programming or in Modern C++ Design where each
template parameter's position in the argument list is "hardwired".
Using the typelist makes selecting various combinations and
overriding options significantly simpler and less verbose.

Options passed to the generator can either be enumeration values
(selected via SetOptionValue), or types (selected via
SetOptionType). The first parameter is either a struct tag (in the
case of type options), or an enumeration type (in the case of value
options). Value options can be used to select an abstract option
that results in the selection of a generator-defined policy. Type
options can be used to provide the generator with "custom" user-
supplied policies. Extending the car factory metaphor used in
Generative Programming, this is a lot like telling the factory, "I
want a fast car with a manual transmission (value options), but I
want you to install my custom stereo and these special tires (type
options). This would result in a car with a V8 and the correct
transmission (along with everything needed to make that combination
work), as well as the custom options provided by the client.

As described above, the generator searches the option typelist for
each type of option that can be set by a client. Using that
information, appropriate policies are selected and passed to the
actual policy-based library class, which becomes typedefed as "Type"
inside the generator.

Incidentally, I stumbled onto an interesting construct that can help
to limit which option values can be selected. I'm sure it's been
done before, but I though you might be interested. The
SetOptionValue is defined as follows:

template <class Option_, Option_ Value_>
struct SetOptionValue
    typedef Option_ Option;
    enum { Value = Value_ };

What is so cool about this is that if Option_ is an enumeration type,
then Value_ *MUST* be one of the symbolic constants defined by that
enumeration. It's a neat trick that forces enumerated value options
to only be set to one of symbolic values specified by the enumeration

Anyway, the value I see in applying generative programming to a
policy based design is that a very complex, highly configurable
library can expose a very simple and expressive interface that allows
options to be selected using domain language (but still allowing
further policy-based customization). I hope you find this
interesting; your opinions would be greatly appreciated, of course.
And if you have any questions about the details of the approach, I
would, of course, be happy to provide more information.

Tim Woodard

Boost list run by bdawes at, gregod at, cpdaniel at, john at