Re: [boost] Re: MPL containers and algorithms

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-11 14:24:01

>From: "Paul Mensonides" <pmenso57_at_[hidden]>

>>From: "Terje Slettebø" <tslettebo_at_[hidden]>

>> > I agree with this as far as pure metaprogramming goes, and I like this
>> aspect of
>> > the STL.  It is a different situation when you are using
metaprogramming
>> > to facilitate real code.
>>
>> In what way could the use of template template parameters, rather than
>> classes with member templates, be of help here, you mean?

>When mixing metaprogramming into normal code.  For instance binding a
certain
>template with too many elements to a template parameter, etc.

Arity checking?

Well, you can do that with classes with member templates, too, using other
ways.

>> > A template-template binding and deduction mechanism would
>> > be useful for such a thing.  Also, if we don't use it, it is not likely
to
>> get improved. :)
>>
>> I understand what you mean. I think Andrei has proposed, for template
>> template parameters, something like "template Function", rather than the
>> current syntax "template<class> class Function", so that it wouldn't be
>> restricted to a certain arity.
>>
>> However, this would still mean you couldn't mix it with types, as you can
>> now, using types, with member templates.
>
>At some point, it comes down to the actual types, values, or "template
>templates"--as demonstrated by the multiplies example that you had.  At
some
>level, you have to do that.  You can't get around the differences totally;
you
>can only delay the point at which they have to be handled specifically.

True. But it means they can be treated generically in many context. For
example with the "pow" example I had, yes. This means you may avoid a lot of
duplication, as one routine may work for a lot of types. In fact for any
type that implements the required concept. In the "pow" algorithm, this
means they must have the metafunctions that are used in the metafunction.

This is similar again to STL, where an entity conforming to the concept may
be used. In run-time programming, we have overloaded functions and
operators. In compile-time programming, we may achieve the same by
specialising templates (metafunctions).

>> > > It seems we agree on the complexity of passing templates around, in
the
>> > > general case. If you don't wrap them up, it will simply collide all
over
>> the
>> > > place. You won't be able to treat metafunctions as first-class
citicens,
>> and
>> > > I think such uniform, generic treatment is key to its power. It lets
you
>> > > relatively easily transform metafunctions, store them, pass them
around,
>> > > etc.
>> >
>> > I don't disagree with the utility of this abstraction.  However, I do
>> disagree
>> > with this reason for it.  You can easily encode any of the above into a
>> type at
>> > will.  What that engenders is a simple subset with more elaborate
designs
>> built
>> > on top of it.
>>
>> I don't think I understood you, here. The question was using templates vs
>> using classes with member templates. Could you try to explain, or give an
>> example?
>
>I don't think they would collide all over the place.  However, I'm not
>advocating the necessary tools to solve that problem.  It isn't worth it.
I
>like this part of the MPL's abstraction, but I do think that we need this
type
>of stuff for a true metaprogramming library at some point.

Support for that is something that could be added, as well, I guess.

Regards,

Terje