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

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-23 14:00:36

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

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

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):

    // 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

I have also considered something along the lines of:

    // for each element in the default list
    //   if the feature_list does not have the feature
    //     transforms the feature_list by ::inject<feature_list>
    compute_defaults
    < class feature_list
    , class default_list // elements have ::feature & ::inject<f_lst>::RET
    >::RET

This would allow the processing of defaults to be specified quite
conveniently. Unfortunately compute_defaults would not compile with MSVC++
6.0, so I have not implemented it (it would be trivial), yet.

I believe that it should also be possible to develop more powerful ways to
represent and manipulate configuration DSLs.

Note that in both of the generative libraries, the default for one feature
can have arbitrary dependencies to other features. This considerably reduces
the amount of explicit features that the user has to specify for common
usage patterns.

Regards,
  Vesa Karvonen

----- Original Message -----
From: "Jeremy Siek" <jsiek_at_[hidden]>
To: "David Abrahams" <abrahams_at_[hidden]>
Cc: "Boost_at_Yahoogroups. Com" <boost_at_[hidden]>; "Jeremy Siek"
<jsiek_at_[hidden]>
Sent: Wednesday, May 23, 2001 20:40
Subject: [boost] Re: Problems with Named Template Parameters

> On Wed, 23 May 2001, David Abrahams wrote:
> abraha> First, a question: is anyone out there using this feature
successfully?
>
> I have.
>
> abraha>
> abraha> 1. When I try to use it, GCC chokes on whatever the last parameter
in my
> abraha> 3-parameter chain is. It complains (incorrectly) that I'm passing
a non-type
> abraha> parameter where the template expects a type.
>
> This sounds bad.
>
> abraha> 2. When I forgot to supply a Distance parameter for my iterator
adaptor
> abraha> wrapping a non-iterator Base type, I got other errors which I had
lots of
> abraha> trouble diagnosing. The code for handling the named template
parameters is
> abraha> so complicated and without substantial comments that it's hard to
understand
> abraha> what's going on.
> abraha>
> abraha> Finally, these remarks:
> abraha>
> abraha> It looks like the code we have in iterator_adaptor_test.cpp for
testing the
> abraha> named template parameter technique is inadequate, since it only
tests one
> abraha> case where no default parameter values are used. It didn't reveal
the
> abraha> problem I'm having with GCC. Given this and the complexity of the
code I am
> abraha> tempted to roll back the feature until more people than just
Jeremy can
> abraha> understand it.
>
> I'd be ok with that, just let me know so I can make sure that I can update
> places where I use it.
>
> abraha> When using the named template parameter approach in a template, it
could get
> abraha> a bit unweildy because instead of writing e.g., ::value_type<T>
you need to
> abraha> write ::template value_type<T>. I think our documentation should
make
> abraha> mention of this and we should consider whether there are ways to
cut down
> abraha> the syntax.
>
> That's a good point. There are some alternatives that don't have this
> problem, like using separate wrappers for each parameter instead of
> nesting them.
>
> Cheers,
> Jeremy
>
>
> ----------------------------------------------------------------------
>  Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
>  Ph.D. Candidate                  email: jsiek_at_[hidden]
>  Univ. of Notre Dame         work phone: [phone]
> ----------------------------------------------------------------------
>
>
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>