Boost logo

Boost Users :

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.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at