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

Subject: Re: [boost] [range][string_algo] Conflict between algorithm names
From: Neil Groves (neil_at_[hidden])
Date: 2010-04-02 11:55:15

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.
>
>
I agree that this is the optimal solution. Boost.Range will implement all of
the standard algorithms, while extensions to the standard especially the
string algorithms that are already very well implemented in Boost.Algorithm
should remain there and I will not duplicate them.

> 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.
>

I shall examine the find implementation over the Easter weekend and see if I
can make it work in a manner that does not cause surprise to users of
Boost.Range. The current standard algorithms all have a formulaic signature
based upon the standard. I'm confident that minor alterations can be
accommodated. I'm certainly more than happy to be flexible to resolve our
interface conflicts. I'll let you know how I get on, hopefully I will be
able to make a commit to the trunk this weekend.

>
> 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.
>
>
Let's see how good we can make your first solution work. I would rather not
break any existing code if possible.

> Regards,
> Pavol
>
>
Thanks for putting these ideas forward. I'll get back to you soon.

Regards,
Neil Groves