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
              typename N
            , typename T
        struct apply
            typedef typename select_if<
                , typename next<N>::type
                , N
>::type type;

    } // namespace aux

          typename Sequence
        , typename Predicate
    struct count_if
        typedef typename fold<
            , 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.


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