Re: [Boost-users] [range] count vs count_if

Subject: Re: [Boost-users] [range] count vs count_if
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2012-02-14 15:16:22

> On Tue, Feb 14, 2012 at 11:26 AM, Bill Buklis <boostusr_at_[hidden]> wrote:
> > struct data
> > {
> >    int a;
> >    int b;
> > };
> >
> > // function object that takes two data parameters - contents unimportant for
> > the example
> > struct match_data;
> >
> > std::vector<data>    data_range;
> > data                            search_value;
> >
> > boost::find_if( data_range, boost::bind(match_data(), _1, search_value) );
>
> Interesting question. How about:
>
> boost::begin(data_range | filtered(boost::bind(match_data(), _1,
> search_value))); ?

Yup, and then you can call base() on the resulting filter_iterator to recover the
iterator into the original range (if you need that).

The broader point, I think, is that the statement in the documentation for range
adaptors that they obsolete the "_if" variants of algorithms, is misleading at best.
The "_if" variant reduces to the plain version + filtered adaptor only in cases 
where the  "_if" variant adds an additional constraint over the plain version 
(as in e.g. copy_if). 

For algorihms where the "_if" variant is a generalization of the plain version (i.e. 
the constraint "the range element is equal to the given value" is generalized to 
"the range element satisfies this predicate" (e.g. count_if, find_if), the "_if" variant
does *not* reduce to the plain version + filtered adaptor. 

We happened to be able to reduce  count_if and find_if to  *other* range algorithms
 + filtered adaptor, because we found other range algorithms that do what we
want (namely, distance() and begin()), but in general such a different range 
algorithm (that combines with the filtered adaptor to do what the "_if" version of
the original algorithm did) may not exist.

Regards,
Nate