Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at