
On Tue, Feb 14, 2012 at 11:26 AM, Bill Buklis
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