aschoedl@… — Mon, 10 Jan 2011 17:36:51 GMT

IMO, boost::range::find should be available as boost::find, while the boost::algorithms::string:find should be changed, because the Finder concept there is farther away from the standard.

Neil Groves — Thu, 17 Mar 2011 00:10:56 GMT

I'm slightly confused by this report. boost::range::find is available as boost::find due to the using range::find in boost/range/algorithm/find.hpp.

I have used the idiom of putting the algorithms in the range namespace and then bringing the functions into the boost namespace. This allows disambiguation when clashes occur with Boost.Algorithm.

IIRC I modified Boost.Algorithm to use the boost::algorithm namespace and pull the functions into the boost namespace with a using clause.

Is this solution not working for you in a use-case I haven't considered? Or are you suggesting that Boost.Algorithm should break backward compatibility to remove the collision when both headers are Boost.Range and Boost.Algorithm headers are included?

I personally believe that there is merit in removing Boost.Algorithm find from the boost namespace for exactly the reason you outlined, namely that the semantic doesn't gel with the standard. However, I believe this would be unacceptably inconsistent without moving find_first, ifind_first, find_last, ifind_last, find_nth, ifind_nth, find_head, find_tail, find_token too.

status changed; resolution set

Neil Groves — Sun, 22 May 2011 21:06:17 GMT

status new → closed
resolution → invalid

Marked as invalid due to a lack of response to my earlier questions. Any change should be made to Boost.Algorithm.

Boost C++ Libraries: Ticket #5057: boost/algorithm/string/find.hpp name-clashes with boost/range/algorithm/find.hpp

status changed; resolution set