Re: [boost] Re: Re: How to do this in withboost--assert(typeid(T)==typeid(bool) )

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-11 21:43:05

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

> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
>
>> <snip>
>>
>> AFAICT from browsing it quickly, the significance of TTP in your code
>> is that you are passing templates instead of types as functions in the
>> interfaces to your metafunctions, which I think is inadvisable,
>> because it eventually breaks metafunction polymorphism.
>
> Not really.  That is the purpose of various types of partial binding
> constructs.  The only real way to break metafunction polymorphism is to use
> non-type template arguments in the the template template parameters, and not
> even that will totally break it.  

I mean that if a metafunction is a template instead of a type you
can't treat it polymorphically with other things, e.g. you can't put
it in a type sequence.

> Strictly not using template template parameters has its own problems
> since you can't pass namespaces as arguments, etc..  This can
> complicate a design real quick as you make more and more
> "indirection" layers:
>
> struct metafunction {
>     template<class T> struct actual_metafunction {
>         // ...
>     };
> };
>
> vs.
>
> template<class T> struct metafunction {
>     // ...
> };

mpl::lambda handles the transformation from the latter to the former.

> I'm not saying the convention is bad, just that it has its own set of
> associated problems.
>
>> Other than that, the final interface you show is one that's acheivable
>> without TTP at all.
>
> Yes, you can do it without TTP, but it isn't as clean.  (I only had a rough
> idea in my head when I made the remark.)  You pay a price for the
> abstraction that you mention by "metafunction polymorphism."  

Hmm?

> The difference is that I prefer to do that abstraction external to
> the core implementation and provide a bridge layer for common
> usages.  In any case, it turns out to be slightly longer anyway
> because I forgot about the need for ::template when one (or all) of
> the parameters a dependent.  

Yes, the language syntax gets in the way.

> However, I was going for a general purpose "iterative OR" when I
> started it, rather than just a solution to the particular problem.
> I basically just had a general idea of something like this:
>
> contains<T>::arg<int>::arg<double>::arg<std::string>::value
>
> ...but the "::template" makes it longer:
>
> contains<T>
>     ::template arg<int>
>     ::template arg<double>
>     ::template arg<std::string>
>     ::value
>
> Altogether, I'm quite pleased with the mechanism, as I find the linear
> typelist implementation "neat," and I've never seen anything like that
> implementation.  

libs/python/test/if_else.cpp might be of interest to you.

> The template classes "fold_left" and "fold_right" are not
> even metafunctions in any normal sense.  I wouldn't know what to call them!

They're interesting to a point, but inflexible.  Any given usage is
restricted to working on sequences of a particular length.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution