Re: [boost] Meta function variants of mpl::apply_if neccesary?

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-09-20 06:43:56

>From: "Aleksey Gurtovoy" <agurtovoy_at_[hidden]>

>Terje Slettebø wrote:
> In the posting with my "factorial" metafunction
> (http://aspn.activestate.com/ASPN/Mail/Message/1316005), I
> propose to make the metafunctions evaluate their own arguments
> (apply "::type" to them), just like it happens in run-time functions.
> With that, the factorial example becomes (quoting from my posting):
>
>> "value" is another new metafunction. It's a way to provide a generic
>> constant, of the type given in the first argument, and the
>> value given in the second. Thus, if "Value" is int_c<...>, then
>> "value<Value,1>::type" is int_c<1>.
>
>mpl::integral_c<..>?

I understand you haven't had a chance to read the post-review postings, as
you say below here, because in the one where I introduced "value," I
explained that it was a way to provide a generic constant, so that a
metafunction could use any value type (integral_c, int_c, rational_c,
fixed_c, etc.), rather than having to write one for each, and it still
wouldn't work for any new type.

It works like this: If Type is e.g. integral_c<...>, then
"value<Type,0>::type" gives integral_c<0>. If Type is rational_c, then it
gives rational_c<0,1>, etc.

>> If the metafunctions, like plus, evaluated their own arguments, as
>> suggested, you could write it like this
>>
>> I found that such a change of MPL would greatly simplify
>> writing code for it, as you avoid having to create ad-hoc templates
>> (like your "recurse", above), just to avoid premature instantiation
>> (evaluation) of some_type_2.
>> Thus, you can write the code in a natural way, not having to
>> spread it out.
>> I found this spreading out to be similar to how template
>> specialisations spreads code, which is what functions like apply_if
>> is meant to avoid. You also avoid all those "::type"s in the code.
>
>I considered and re-considered the idea a couple of times during MPL
>development. It doesn't really work well; in particular, it conflicts with
>the notion of nullary metafunctions, pretty much making the library useless
>for manipulating the latter ones:

<snip>

I understand. Thanks for the explanation.

>> Paul Mensonides replied at the time that he found this a
>> sensible solution to it. However, I haven't heard anything on this
>> issue from others, such as Aleksey or Dave.
>
>That's because I am yet to read those 200+ post-review MPL-related messages
>that were posted during the 3-weeks period when I was out of country :).

That makes sense. :)

Regards,

Terje