[boost] Re: Re: Re: Re: Re: Re: Re: Adding Loki to Boost (reprise)

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-14 21:36:34

Joel de Guzman wrote:
> > Let's not make unfounded statements here, even implicit ones. I am
pretty
> > sure that someone familiar with the library will write
> > 'gen_linear_hierarchy' much more faster using MPL facilities than any
C++
> > metaprogramming expert using "C++ only" (or, FWIW, Loki), and her
version
> > will work on much greater number of compilers. If this doesn't fall
under
> > your definition of "facilitate", then we are talking in different
> > dimensions.
>
> I beg your pardon. This is not unfounded. Your *original* version of
> count_if *does not* facilitate metaprogramming at all.

Okay, here it is again:

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

Here's what it does:

1) It implements 'count_if' algorithm that works for any type sequence which
is a model of MPL ForwardSequence concept;
2) It works on compilers without partial specialization.
3) It works on Metrowerks Codewarrior (always).
4) It works on large sequences with complex predicate.
5) It cuts down compilation time on large sequences.
6) It's possible to explain to someone who is familiar with
'std::accumulate' without introducing her to Lisp history, patterns-matching
and techniques of converting iterational algorithms to recursive ones.

Now, try to write a version of 'count_if' that implements all the above
points without using the library, and compare the results. If this is not
that is called to "facilitate", then I am sorry for terminology-based
misunderstanding.

> This is of course
> my opinion and the opinion of others as well. It just so happens that
> this opinion is contrary to yours, but that does NOT make it "unfounded".

I didn't mean to offend you. Hope the above clarifies my point.

>
> > There is very little special semantics one need to learn about "MPL's
> > version of fold". The basic usage is exactly the same as in most FP
> > languages, and matches the semantics of 'std::accumulate' as well - it
takes
> > a sequence, an initial state, a binary metufunction-class, and returns
the
> > result of sequential application of the metafunction-class to each
element
> > of the sequence and the previous state. "Tried and true pattern matching
+
> > recursion patterns" is unfamiliar to most C++ programmers that have
never
> > been exposed to template metaprogramming before.
>
> Of course not. We *were* talking about your *original* version of
fold_iter
> (or whatever) and all the excess baggage that comes with it. You are
taking
> this out of context. My previous post that you are replying to now was
> based on your *original* count_if version.

So what? The 'fold' algorithm didn't change between these posts.

> I am trying my best here to open up my mind. FWIW, I am not using Loki
> at all. I am in the middle ground here. I am really wanting to use MPL.
> However, your comments and replies seem to indicate that you are
> not willing to take in outside opinion. You state that other opinions
> contrary to yours are "unfounded". For that, I am deeply saddened.

I _do_ appreciate your comments. And it's not about Loki vs. MPL (at least
not this sub-thread :). And I am not trying to disqualify anyone's posts
basing on the criteria that their opinion is different than mine. I said
what I think regarding an implicit statement of MPL not facilitating
metaprogramming - basing on the technical merits.

Aleksey