[Range] contains() for unsorted ranges?
Hello, Wouldn't the library be well served by providing a contains() algorithm - with the same overloads/versions as find - for unsorted ranges? Surely, having to test against the range's end ruins the otherwise expressive syntax offered; especially when adaptors are involved and one has to test against the adapted range's end. Perhaps I am missing an obvious reason why not? Albert -- kojirion.github.io
Wouldn't the library be well served by providing a contains() algorithm - with the same overloads/versions as find - for unsorted ranges? Surely, having to test against the range's end ruins the otherwise expressive syntax offered; especially when adaptors are involved and one has to test against the adapted range's end. Perhaps I am missing an obvious reason why not?
I can't think of a reason. In my code I wrote my own version of this function and I use it all the time. If you're interested in contributing such a function to Boost.Range (including tests and documentation), I'd be happy to review it. Regards, Nate
On 06/04/14 20:52, Nathan Ridge wrote:
If you're interested in contributing such a function to Boost.Range (including tests and documentation), I'd be happy to review it.
Sure, I would be happy to do so; first I need to examine how the tests and docs are written, Albert -- kojirion.github.io
On Mon, Apr 7, 2014 at 1:07 AM, Albert Yiamakis <vkicefire@gmail.com> wrote:
On 06/04/14 20:52, Nathan Ridge wrote:
If you're interested in contributing such a function to Boost.Range (including tests and documentation), I'd be happy to review it.
Sure, I would be happy to do so; first I need to examine how the tests and docs are written,
I'm grateful for the offer of assistance. I would like to point out that you can already do this quite nearly like this: boost::find<boost::return_found_end>(rng, x) since the iterator_range will convert to bool. When it is empty it is not present, when it is not empty there is at least one element. This idiom also automatically works for find_if and many other algorithms. Therefore explicitly making a special-case for find seems unnecessary and perhaps a step backwards. The above is simply my viewpoint. I am currently satisfied with the way this works. I am keen to avoid numerous special-cases, but I am open to persuasion. What this does probably show is that I need to improve my documentation. This is not clear from the current documentation. Albert Regards, Neil Groves
On 08/04/14 14:24, Neil Groves wrote:
I would like to point out that you can already do this quite nearly like this: boost::find<boost::return_found_end>(rng, x) since the iterator_range will convert to bool.
Thanks for pointing out this idiom. Meanwhile, I have discovered that Boost.Algorithm's any_of and any_of_equal: http://www.boost.org/doc/libs/1_55_0/libs/algorithm/doc/html/the_boost_algor... work with ranges out of the box, eliminating the need to use find or find_if for this purpose. Note also that there is also a contains() to test whether a range is contained, buried in <boost/algorithm/string/predicate.hpp>. Perhaps these should be presented in the documentation instead? Albert
participants (4)
-
Albert Yiamakis -
Nathan Ridge -
Neil Groves -
Vee Kay