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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-04-12 22:45:02

Joel de Guzman wrote:
> > Well, with a few simplifications, the above could be easily adopted as
an
> > MPL 'count_if' algorithm implementation. In the toy world :). Just a few
> > points:
> >
> > 1) The above doesn't work on compilers without partial specialization.
> > 2) There are cases when the above doesn't work on Metrowerks Codewarrior
> > (all versions).
> > 3) When the predicate is complex, the above doesn't work on large
sequences
> > (> 50) because of the limits on the nested template instantiation depth
> > (some of the compilers don't have a direct (or any) mechanism of
increasing
> > the limit).
> > 4) The above looses the opportunity to cut down compilation time on
large
> > sequences.
>
> But why should we pay for the inadequacies of compilers?

The above is not only about "inadequacies of compilers", it's also about
compile-time performance. And you don't have to. Remember, it's
_implementation_ of 'count_if' we are talking about here. If your compiler
is ideal, and you believe that you don't need something like recursion
unrolling (believe me, you do :), you are free to contribute an
implementation of the algorithm like the one Peter has posted here; it can
be incorporated conditionally. IMO it doesn't worth it, though.

> I firmly believe that we should push these compilers hard to
> send a strong message to the compiler makers not to be lax.

I definitely think that compiler vendors need to be pressed towards the
better comformance. But the above sounds like it's library's fault that it
does work under deficient compilers. Do you seriously think so? How about
Phoenix? By that criteria it's guilty as well :).

FWIW, _none_ of the current compilers is not able to handle MPL without all
workarounds, so if you want the "ideal" implementation (whatever it is),
than this discussion is meaningless, because you first should wait for that
ideal compiler to appear.

> I am having the impression now that MPL's interface was designed
> in part to get around these limitations?

Why? Were we discussing the 'count_if' interface here? I believe not.

> If so, this is not a good sign.

It is not so.

>
> > 5) (IMO) The above is too low-level, and harder to parse and understand
when
> > the original 'fold' version.
>
> Sorry, but I do not agree. Peter's and Andrei's versions are
> easier to understand. At least for me (no offense meant :-)

Are you familiar with functional programming?

Aleksey