Subject: Re: [boost] Boost.RangeEx: contains?
From: Neil Groves (neil_at_[hidden])
Date: 2009-02-22 15:27:54
On Sun, Feb 22, 2009 at 7:55 PM, Eric Niebler <eric_at_[hidden]>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
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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk