Re: [boost] Named Template Parameters

From: David A. Greene (greened_at_[hidden])
Date: 2002-08-06 17:52:03

Jeremy Siek wrote:

> BTW, your email text keeps showing up as an attachment, which makes it
> impossible for our email reader (pine) to quote it properly in the reply.

Ok, I'll keep that in mind for the future.  Thanks for your comments!

>>The example includes a car structured as taking a typelist of
>>NTPs and a car taking individual scalar NTPs as in the sandbox
>>example.  I was quite pleased at how easy it was to implement the
>>latter on top of the former.
> 
> Inheritance is a pain to use like this... in a real class you'd need
> forwarding constructors :( Also there are other problems, for example, if
> you tried to implement iterator_adaptor using that approach you would have
> troubles with the return type of operator++, which has to be by-value, and
> the same type as the most-derived class.

Absolutely.  I didn't mean for it to be a be-all example of how
to implement things.  I simply wanted to reproduce the car example
as closely as possible and found a convenient way to do it.  Not
much thought went into this part.

>>  // Set the model and tranny
>>  typedef mpl::make_typelist_2<mpl::ntp<model_tag, limited_edition>,
>>                               mpl::ntp<transmission_tag, manual> >::type
>>    limited_manual_config;
>>   car_as_typelist<limited_manual_config> limited_manual_car;
> 
> The above syntax is less clear than our current appraoch:
> 
> typedef car< Model_is<limited_edition>, Transmission_is<manual> >
>    limited_manual_car;

Yep, I agree 100%.  If the C++ syntax wasn't so ugly, we could
have something like ntp<model>::is<limited_edition> but
ntp<model>::template is<limited_edition> is atrocious.

We could get closer with ntp<model_is, limited_edition>.

>>I see two main advantages to this alternate approach:
>>- Declaration of parameters and defaults is decoupled from
>>   the binding of parameters to defaults.  No car_defaults is
>>   necessary though it could of course be used for convenience.
>>   Model_is, etc. are replaced by the "standard" ntp<> class.
> 
> This seems pretty minor to us.

Maybe.  It's less burden for the class designer in that Model_is
doesn't exist and ntp doesn't derive from car_defaults the way
Model_is does.  Why should Model_is care about the other defaults?
Just seems less complicated to me, but that may be personal
preference kicking in.

>>- The use of typelists allows an arbitrary number of template
>>   parameters.  I can't say with absolute certainty until I play
>>   around with this some more, but I think I can get all of the
>>   functionality of the sandbox NTP with the typelist mechanism.
> 
> There is no need for this. At design time you know how many template
> parameters (or features) are be needed.

I've been kicking this around a bit.  Wouldn't it allow some
decoupling of template parameter processing (the "class
metaimplementation") from the class interface, similar to the
pimpl idiom?  Now, in all practicality it might not work
because of compiler limitations, but I see an analogy between
pimpl and typelists.  Just as pimpl provides a single entry
point to an arbitrarily complex data structure, a typelist
provides a single (template parameter) entry point to an
arbitrarily complex data structure of types.

This sort of thing can allow template interface wrappers
around template impl classes.

Maybe it's not all that useful but it's fun to think about.  :)

In any event, I've seen calls in various places (c.l.c++.m
and here, I think) for variable-length template parameter
lists.  What are those good for?  Typelists seem to provide
the same functionality.  Well, in the same way std::vector
provides variable-length function argument lists.  :)

Again, thanks for your comments.

                         -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson