boost/algorithm/string/find.hpp name-clashes with boost/range/algorithm/find.hpp

[aschoedl@…]

Both provide a boost::find with all parameters being templates.

[aschoedl@…]

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]

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.

[Neil Groves]

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