Re: [boost] [range][string_algo] Conflict between algorithm names

Subject: Re: [boost] [range][string_algo] Conflict between algorithm names
From: Pavol Droba (droba_at_[hidden])
Date: 2010-04-01 18:51:14

Hi,

On 29. 3. 2010 20:07, Jeremiah Willcock wrote:
> On Mon, 29 Mar 2010, Mathias Gaunard wrote:
> 
>> Jeremiah Willcock a écrit :
>>> When I try to include both Boost.Range algorithms (in the current
>>> trunk version) and Boost.Algorithm, using a file such as the following:
>>>
>>> #include <boost/algorithm/string.hpp>
>>> #include <boost/range/algorithm.hpp>
>>>
>>> I receive several errors about duplicate definitions.
>>
>> I reported that problem in July last year, but although I did get an
>> answer from the author that he would look into it, nothing changed.
>>
>> I suppose you should file a ticket, that's more useful than the list.
> 
> Which component should it be for?  range or string_algo?
> 

My appologies for not answering on time. I saw the ticket, in the trac but as matter of fact
I didn't have a clear idea how to fix this issue.

Looking through the code, I see some ways to solve the issues.

1.lexicographical_compare.
 The conflicting version are same in-fact. The real difference lies in ilexicographical_compare
 that is not present in Boost.Range. boost::algorithm::lexicographical_compare can be easily
 just forwarded to Boost.Range version to maintain backward compatibility.

2.find
 This is little bit more complicated, since the boost::algorithm::find is a more generic version
of find, presented in the Boost.Range library, which relies on plain std::find.
Maybe the best course of actions would be to adapt whould StringAlgo library to new utilities
provided by Boost.Range and to unify finder/replace stuff under one roof. The only question is
if this is desired on the Boost.Range side.

Alternatively, "using" forward for boost::algorithm::find can be removed, just to avoid conflicts.
It is a specialized algorithm and it would probably not break much of the existing code base.
I assume that it is mostly used indireclty via find_XXX wrappers.

Regards,
Pavol