Re: [boost] Re: Review Request: FC++

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-08 15:49:32

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> {};
    };

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net