Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-11 15:54:43


Joel de Guzman wrote:
> Two points:
>
> 1) Unlike STL's algorithms, writing an MPL algorithm is not as
> straightforward

Why do you think so? Sure, it's different, due to functional flavor of the
domain, but it is straightforward in MPL terms. For example, here's (a
little bit simplified) 'count_if' algorithm implementation:

    namespace aux {

    template< typename Predicate >
    struct next_if
    {
        template<
              typename N
            , typename T
>
        struct apply
        {
            typedef typename select_if<
                  apply<Predicate,T>::value
                , typename next<N>::type
                , N
>::type type;
        };
    };

    } // namespace aux

    template<
          typename Sequence
        , typename Predicate
>
    struct count_if
    {
        typedef typename fold<
              Sequence
            , integral_c<unsigned long, 0>
            , aux::next_if<Predicate>
>::type type;

        BOOST_STATIC_CONSTANT(unsigned long
            , value = type::value
            );
    };

> and there indeed is a core infrastructure that one
> needs to learn in order to write one.

Well, yes, you'll have to learn a couple of things :).

> STL is all about algorithms and allowing the client to write
> custom algorithms is what I really enjoy about its design.

That's very much what MPL is about as well.

> If MPL is to truly follow STLs footsteps,
> such a "guide to the implementation" or should I say "guide to
> writing MPL algorithms" *should* be equally important as a
> user guide.

There will be a "guide to writing MPL algorithms"! Also, I believe that a
couple of sections in the MPL paper (for example, "2.3.4 iter_fold as the
main iteration algorithm") already cover a little bit of the topic.

Aleksey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk