Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-04-12 21:49:36


----- Original Message -----
From: "Aleksey Gurtovoy" :

> Peter Dimov wrote:
> > > The above implementation is useless for 'tiny_list' (and any type
> sequence
> > > we use here at work).
> >
> > Perhaps, but I'd still expect something like (syntax made up):
> >
> > template<class First, class Last, class Pred> struct count_if
> > {
> > enum { value = count_if<typename next<First>::type, Last, Pred>::value
> +
> > Pred::template apply< typename dereference<First>::type >::type::value };
> > typedef ct_value<int, value> type;
> > };
> >
> > template<class Last, class Pred> struct count_if<Last, Last, Pred>
> > {
> > enum { value = 0 };
> > typedef ct_value<int, value> type;
> > };
>
> 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?
I firmly believe that we should push these compilers hard to
send a strong message to the compiler makers not to be lax.
I am having the impression now that MPL's interface was designed
in part to get around these limitations? If so, this is not a good sign.

> 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 :-)

Regards,
--Joel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk