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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-13 07:29:26

From: "Aleksey Gurtovoy" <agurtovoy_at_[hidden]>
> Well, with a few simplifications, the above could be easily adopted as an
> MPL 'count_if' algorithm implementation. In the toy world :).

But that's not the point. Nobody is trying to replace MPL's own count_if.
This is merely an example of a user-defined algorithm.

> 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.

All good and valid points; it's important for a library to be useable in the
real world. What's equally important, however, for a library that aspires to
become part of the C++ standard, is to scale well, i.e. to provide a
no-compromises interface on a "perfect" compiler. Compilers aren't going to
get worse with time. Therefore, if you design your library with compiler
deficiencies in mind, it will become obsolete.

> 5) (IMO) The above is too low-level, and harder to parse and understand
when
> the original 'fold' version.

A fold/reduce version of count_if can indeed be easy to understand [1] given
the right background, but the version I presented is a simple rewrite of the
STL count_if. When in Rome...

--
[1] count_if(v, p) :- fold(v, lambda(x, n)(p(x)? n+1: n), 0).
Your rendition of the above was too hard for me to grok, though.