[range][string_algo] Conflict between algorithm names
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 am using gcc 4.1.2 on Linux. ./boost/range/algorithm/find.hpp:28: error: ‘template<class SinglePassRange, class Value> typename boost::range_iterator::type boost::find(SinglePassRange&, const Value&)’ conflicts with previous using declaration ‘template<class RangeT, class FinderT> boost::iterator_range<typename boost::range_iterator<C>::type> boost::algorithm::find(RangeT&, const FinderT&)’ ./boost/range/algorithm/lexicographical_compare.hpp:28: error: ‘template<class SinglePassRange1, class SinglePassRange2> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&)’ ./boost/range/algorithm/lexicographical_compare.hpp:42: error: ‘template<class SinglePassRange1, class SinglePassRange2, class BinaryPredicate> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T, class PredicateT> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&, PredicateT)’ The using declarations mentioned in the error message are in files such as boost/algorithm/string/find.hpp. Is there a workaround or easy fix for this? -- Jeremiah Willcock
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.
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? -- Jeremiah Willcock
Jeremiah Willcock a écrit :
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?
StringAlgo. The problem, of course, is that it's going to break some existing code.
I suppose you should file a ticket, that's more useful than the list.
Which component should it be for? range or string_algo?
StringAlgo. The problem, of course, is that it's going to break some existing code.
If the patch was submitted in the middle of last year, do we need to make arrangements for someone to apply a fix in a shorter time frame? I'm quite happy to fix the defect regardless of which library requires modification, but I believe the required changes are in Boost.Algorithm and I would not want to cause any frustration. Regards, Neil Groves
On Tue, 30 Mar 2010, Neil Groves wrote:
I suppose you should file a ticket, that's more useful than the list.
Which component should it be for? range or string_algo?
StringAlgo. The problem, of course, is that it's going to break some existing code.
If the patch was submitted in the middle of last year, do we need to make arrangements for someone to apply a fix in a shorter time frame? I'm quite happy to fix the defect regardless of which library requires modification, but I believe the required changes are in Boost.Algorithm and I would not want to cause any frustration.
What is going to happen with this on the release branch in particular? I will be merging over the BGL changes from the trunk and would like to know if the range algorithms will be in there (so I don't need to get them from boost/detail/algorithm.hpp). -- Jeremiah Willcock
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
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
Boost.Range algorithms are only in the trunk, right? Not yet in any numbered release?
Yes I introduced the Boost.RangeEx code merged into Boost.Range on Sunday.
The conflict has been fixed IIRC by Jeremiah by using the Boost.Range implementations rather than duplicating them. I am very interested to hear from anyone that has any issues. I have been reviewing the documentation further and have become aware of a few documentation typos and omissions which I will submit fixes for this weekend. I intend to improve compiler compatibility of the Range Adaptor pipe operator implementations. For now some compilers only work with the alternative function syntax for some of the adaptors. Also I want to move all of the pipe operators into the adaptor namespace, currently some are implemented in range_detail. This doesn't produce any symptoms on modern compilers as far as I am aware since Argument Dependent Lookup finds the correct operator. I would like to hear of any issue with the trunk Boost.Range however small. I have made considerable effort to preserve backward compatibility, but real world experience is of course very valuable. Neil Groves
On Wed, 31 Mar 2010, Neil Groves wrote:
Boost.Range algorithms are only in the trunk, right? Not yet in any numbered release?
Yes I introduced the Boost.RangeEx code merged into Boost.Range on Sunday.
The conflict has been fixed IIRC by Jeremiah by using the Boost.Range implementations rather than duplicating them.
No, I didn't fix any of the Boost.Range/Boost.StringAlgo issues -- some of the BGL test cases don't build because of this bug. I did remove the duplications (conflicts) between <boost/detail/algorithm.hpp> and Boost.Range by switching to Boost.Range, but some test cases use string_algo as well and those are currently broken in the trunk. -- Jeremiah Willcock
participants (5)
-
Jeremiah Willcock -
Mathias Gaunard -
Neil Groves -
Pavol Droba -
Robert Jones