
Boost : 
From: Peter Dimov (pdimov_at_[hidden])
Date: 20020413 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 userdefined 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
nocompromises 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 lowlevel, 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk