Re: [boost] Re: Problems with Named Template Parameters

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-23 16:08:56

----- Original Message -----
From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Cc: ""Jeremy Siek"" <jsiek_at_[hidden]>; <abrahams_at_[hidden]>
Sent: Wednesday, May 23, 2001 3:00 PM
Subject: Re: [boost] Re: Problems with Named Template Parameters

> Hi,
>
> I have also recognized the problem of long template parameter lists a long
> time ago. For my generative programming libraries, I have developed a very
> simple set of utility primitives for handling list based configuration
DSLs.
> List based configuration DSLs should be quite useful from both theoretical
> and practical points of view.
>
> The equivalent of the named template parameter example:
>
>
>
iterator_traits_generator::reference<foo>::category<std::input_iterator_tag>
>
> could be written using the list based configuration DSL + generator
approach
> as follows:
>
>     iterator_traits_generator
>     < make_list
>       < iterator_traits_reference<foo>
>       , iterator_traits_category<std::input_iterator_tag>
>       >::RET
>     >::RET

Which is even heavier on the syntax than what we've got. I'm trying to move
the other direction.

> Alternatively, it would be possible to let the generator take multiple
> parameters, and then make the list inside the generator:
>
>     iterator_traits_generator
>     < iterator_traits_reference<foo>
>     , iterator_traits_category<std::input_iterator_tag>
>     >::RET

I think that would be better, though IMO it would be best if the parameters
were passed directly to boost::iterator_adaptor<> instead.

> This could be conveniently implemented using the PREPROCESSOR library, but
I
> do not consider the increase in code size (and potential increase in
> compiling times) worth the syntactic sugar.
>
> I'm using this approach in my Resource library, but I originally developed
> it for my Container library. Thanks to the technique, the parameters for
the
> generator can be given in any order.
>
> The list DSL utility primitives consist of the following (pseudo code):

What does DSL stand for?

>     // returns the desired feature from a feature list or void
>     get_feature
>     < class feature_list // each element has ::feature
>     , int feature
>     >::RET
>
>     // if the list does not contain the feature, adds the default
>     // into the feature list
>     inject_default
>     < class feature_list
>     , int feature
>     , class default
>     >::RET
>
>     // for each element in the default_list, calls inject_default
>     inject_defaults
>     < class feature_list
>     , class default_list // each element contains ::feature and ::default
>     >::RET

One problem with this approach for iterator_adaptors is that just computing
the default type in cases where it isn't needed can cause compilation
errors. It shows up where the expression std::iterator_traits<Base> is used
and Base is not an iterator. The default type must only be computed when no
argument is supplied.

-Dave