[boost] Re: Review Request: FC++

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 16:23:43

"Joel de Guzman" <joel_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> wrote:
>
>> 2. I strongly urge that you review the conventions used for
>> interoperability with the MPL's idioms.  For example, the definition
>> of mymap from the examples might be:
>> 
>>   struct mymap_type
>>   {
>>       template <class F, class L>
>>       struct apply
>>       {
>>          typedef list<
>>              typename mpl::apply<F,typename L::value_type>::type
>>          >
>>          type;
>>       };
>> 
>>       template <class F, class T>
>>       typename mpl::apply< F, list<T> >::type
>>       operator()( F some_func, list<T> some_list ) const { ... }
>>    } mymap;
>> 
>> 
>> The use of a nested "::apply<>" instead of a nested "::sig<>" makes
>> mymap_type into a *metafunction class*, and the use of a nested
>> "::type" within "::apply" makes it into a *metafunction*.  I'm almost
>> certain that you could take advantage of MPL with these conventions
>> within FC++ for a substantial reduction in code and complexity, and
>> a corresponding increase in portability.
>
> AFAIK, "::apply<> is not equivalent to ::sig<>. sig is the return type
> metafunction of the functoid mymap_type. It is similar to Phoenix's
> result and LL's sig. Consider the square:
>
>     struct square
>     {
>         template <class X>
>         struct sig { typedef X type; }
>         X operator()(X x) { return x * x; }
>     };
>
> This square function becomes entirely different when transformed into
> a metafunction. I'd imagine it to be:
>
>     struct meta_square
>     {
>         template <class X>
>         struct apply : mpl::multiplies<X, X> {};
>     };

Of course.  I'm not suggesting that the nested apply should do the
analagous compile-time computation to operator().  I'm just suggesting
that:

    a. It should be a proper metafunction, returning ::type, for
       interoperability

    b. It should be called apply, because that just makes it cheaper
       and easier to use: instead of

           mymap_type::sig<_1,_2>

       in MPL lambda expressions you can just pass mymap_type (the
       surrounding metafunction class), and you don't need the macro
       workarounds for broken compilers which lambda-enable the
       nested ::sig.
       
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com