"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> ----- Original Message -----
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> <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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
