
Boost : 
From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 20020414 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, patternsmatching
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 terminologybased
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 metufunctionclass, and returns
the
> > result of sequential application of the metafunctionclass 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 subthread :). 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk