Hi Eric, On Sun, Feb 22, 2009 at 7:55 PM, Eric Niebler <eric@boost-consulting.com>wrote:
Mathias Gaunard wrote:
Marcus Lindblom wrote:
I'm just missing basic "contains/contains_if" function, that searches and
retursn a bool on whether an item is in a range. (i.e. find(rng, v) != end(rng) ). I've found those are quite useful. Perhaps this just has another name and I overlooked it?
What about !empty(rng | filtered(_1 == v)).
Sure, and most algorithms can be implemented in terms of fold. It doesn't follow that fold should be the only algorithm. I don't like requiring users to use range adaptors instead of providing algorithms like "find_if" and "contains" that just do what they say.
I'm wrestling with the idea of putting some of the "_if" algorithms back into the range algorithms. As soon as I start to allow the inclusion of some "_if" algorithms, I find it hard to come up with a consistent mental model for what should and should not be implemented as an algorithm. I appreciate that this makes some code easier to read. Do you think that all of the standard algorithm _if, _n versions should be present, or just for some of the most common? Are you of the opinion that for each algorithm one writes there should be _if , _n, _copy, _reverse counter-parts? At some point it seems to place too much burden on the algorithm developer. Any inconsistency in the _if availability starts to add burden to users of the library by requiring them to remember which combinations are available. I can only really see that for very common operations we might want to provide _if versions. I would really appreciate clarification of your views on this matter, since I deeply respect you knowledge of this domain, not to mention the work you have already put into this library.
-- Eric Niebler BoostPro Computing http://www.boostpro.com
Best Wishes, Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost