[Range.Ex / String.Algo] Ambiguous call to overload function "find"
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include<boost/algorithm/string.hpp> #include<boost/range/algorithm.hpp> int main() { std::string s = "hello"; boost::find_first(s, "lo"); return 0; } The compiler will complain ambiguous call to overload function "find". I found there's also a "find" in boost/range/algorithm.hpp. Even worse when I change the type of "s" to const std::string, the compiler will resolute "find" call as the one in boost/range/algorithm.hpp and reports an error "const_iterator is not a member of std::_String_const_iterator". Now I just indicated the "find" call in boost::find_first explicitly. Is there a better way to solve it? Thanks! S.C. Leung
Hello! On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 <shaochiliang@gmail.com> wrote:
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include<boost/algorithm/string.hpp> #include<boost/range/algorithm.hpp>
int main() { std::string s = "hello"; boost::find_first(s, "lo"); return 0; }
The compiler will complain ambiguous call to overload function "find". I found there's also a "find" in boost/range/algorithm.hpp. Even worse when I change the type of "s" to const std::string, the compiler will resolute "find" call as the one in boost/range/algorithm.hpp and reports an error "const_iterator is not a member of std::_String_const_iterator". Now I just indicated the "find" call in boost::find_first explicitly. Is there a better way to solve it?
I'm not sure why there should be any conflict. I will test this problem out over the weekend. Would you please clarify which RangeEx you are using. Are you using the latest version from the vault in the algorithm directory? I appreciate that these difficulties would not occur, if I had managed to get this code into the trunk of subversion.
Thanks! S.C. Leung
Please accept my apologies for the problem. I shall report back to you by Monday 6 July 2009. Regards, Neil Groves
Hi! I have downloaded Range.Ex uploaded at 26.04.2009 09:09. It seems the difficulties are still there. Thank you for your work! S.C. Leung 2009/7/3 Neil Groves <neil@grovescomputing.com>
Hello!
On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 <shaochiliang@gmail.com> wrote:
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include<boost/algorithm/string.hpp> #include<boost/range/algorithm.hpp>
int main() { std::string s = "hello"; boost::find_first(s, "lo"); return 0; }
The compiler will complain ambiguous call to overload function "find". I found there's also a "find" in boost/range/algorithm.hpp. Even worse when I change the type of "s" to const std::string, the compiler will resolute "find" call as the one in boost/range/algorithm.hpp and reports an error "const_iterator is not a member of std::_String_const_iterator". Now I just indicated the "find" call in boost::find_first explicitly. Is there a better way to solve it?
I'm not sure why there should be any conflict. I will test this problem out over the weekend. Would you please clarify which RangeEx you are using. Are you using the latest version from the vault in the algorithm directory? I appreciate that these difficulties would not occur, if I had managed to get this code into the trunk of subversion.
Thanks! S.C. Leung
Please accept my apologies for the problem. I shall report back to you by Monday 6 July 2009.
Regards, Neil Groves
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
2009/7/3 S.C. Leung <shaochiliang@gmail.com>
Hi! I have downloaded Range.Ex uploaded at 26.04.2009 09:09. It seems the difficulties are still there.
The exact program you posted compiles without errors or warnings on Visual C++ 9. I installed Boost 1.39 and then copied over the RangeEx files. [...]
009/7/3 Neil Groves <neil@grovescomputing.com>
Hello!
On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 <shaochiliang@gmail.com> wrote:
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include<boost/algorithm/string.hpp> #include<boost/range/algorithm.hpp>
int main() { std::string s = "hello"; boost::find_first(s, "lo"); return 0; }
The compiler will complain ambiguous call to overload function "find". I
found there's also a "find" in boost/range/algorithm.hpp. Even worse when I change the type of "s" to const std::string, the compiler will resolute "find" call as the one in boost/range/algorithm.hpp and reports an error "const_iterator is not a member of std::_String_const_iterator". Now I just indicated the "find" call in boost::find_first explicitly. Is there a better way to solve it?
This code compiles cleanly for me. I noticed that you are talking about "find" rather than "find_first" so I took the liberty of replacing the "find_first" with "find". This indeed produced a compiler error similar to the one you describe. However boost::find(s, "lo") does not match the boost/algorithm/string.hpp version because the second parameter should be a "Finder object used for searching". Please see: http://www.boost.org/doc/libs/1_39_0/doc/html/string_algo/reference.html#hea... It also does not match the RangeEx version because "find" is used to find an element, as opposed to a sub-sequence, from a range. Therefore I conclude that either, I have guessed the code snippet that causes the problem inaccurately, or that the code that produced the compiler error was simply incorrect. If I have guessed the code wrongly, would you please supply the exact code that reproduces the problem. I suspect that find_first is exactly the right solution. Please let me know either way. [...] Regards, Neil Groves
That's too strange. Maybe the test environments between us are different so I want to send you the range_ex.zip I use. By the way, the "find_first" really call the "find" by making a "Finder object" and that's where the resolution failed. I'm also not sure if the compiler options have side effects so I post my options as below: /Od /D "_MBCS" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt Lastly, have you replaced std::string with const std::string? That will cause the "find" within "find_first" resoluted as the "find" in range/algorithm/find.hpp in my test environment. Thank you for your work! S.C. Leung 2009/7/5 Neil Groves <neil@grovescomputing.com>
2009/7/3 S.C. Leung <shaochiliang@gmail.com>
Hi! I have downloaded Range.Ex uploaded at 26.04.2009 09:09. It seems the difficulties are still there.
The exact program you posted compiles without errors or warnings on Visual C++ 9. I installed Boost 1.39 and then copied over the RangeEx files.
[...]
009/7/3 Neil Groves <neil@grovescomputing.com>
Hello!
On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 <shaochiliang@gmail.com> wrote:
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include<boost/algorithm/string.hpp> #include<boost/range/algorithm.hpp>
int main() { std::string s = "hello"; boost::find_first(s, "lo"); return 0; }
The compiler will complain ambiguous call to overload function "find".
I found there's also a "find" in boost/range/algorithm.hpp. Even worse when I change the type of "s" to const std::string, the compiler will resolute "find" call as the one in boost/range/algorithm.hpp and reports an error "const_iterator is not a member of std::_String_const_iterator". Now I just indicated the "find" call in boost::find_first explicitly. Is there a better way to solve it?
This code compiles cleanly for me. I noticed that you are talking about "find" rather than "find_first" so I took the liberty of replacing the "find_first" with "find". This indeed produced a compiler error similar to the one you describe. However boost::find(s, "lo") does not match the boost/algorithm/string.hpp version because the second parameter should be a "Finder object used for searching". Please see:
http://www.boost.org/doc/libs/1_39_0/doc/html/string_algo/reference.html#hea...
It also does not match the RangeEx version because "find" is used to find an element, as opposed to a sub-sequence, from a range. Therefore I conclude that either, I have guessed the code snippet that causes the problem inaccurately, or that the code that produced the compiler error was simply incorrect.
If I have guessed the code wrongly, would you please supply the exact code that reproduces the problem. I suspect that find_first is exactly the right solution. Please let me know either way.
[...]
Regards, Neil Groves
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
S.C. Leung skrev:
That's too strange. Maybe the test environments between us are different so I want to send you the range_ex.zip I use. By the way, the "find_first" really call the "find" by making a "Finder object" and that's where the resolution failed. I'm also not sure if the compiler options have side effects so I post my options as below:
/Od /D "_MBCS" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt
Lastly, have you replaced std::string with const std::string? That will cause the "find" within "find_first" resoluted as the "find" in range/algorithm/find.hpp in my test environment.
I think the problem might be related to ADL. All boost libraries should guard against this. For example, in the string library, forwarding calls should be to boost::algorithm::foo and also in the range library, forwarding calls should use boost::ranges::foo -Thorsten
Hello, Thorsten: Have you test my case and had the same problem with me? Does it mean that the library should call the function explicitly? Thanks! S.C. Leung 2009/7/6 Thorsten Ottosen <thorsten.ottosen@dezide.com>
S.C. Leung skrev:
That's too strange. Maybe the test environments between us are different so I want to send you the range_ex.zip I use. By the way, the "find_first" really call the "find" by making a "Finder object" and that's where the resolution failed. I'm also not sure if the compiler options have side effects so I post my options as below:
/Od /D "_MBCS" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /errorReport:prompt
Lastly, have you replaced std::string with const std::string? That will cause the "find" within "find_first" resoluted as the "find" in range/algorithm/find.hpp in my test environment.
I think the problem might be related to ADL. All boost libraries should guard against this. For example, in the string library, forwarding calls should be to
boost::algorithm::foo
and also in the range library, forwarding calls should use
boost::ranges::foo
-Thorsten
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung <shaochiliang@gmail.com> wrote:
Hello, Thorsten: Have you test my case and had the same problem with me? Does it mean that the library should call the function explicitly?
Did you try the patch for Boost.Algorithm that I supplied in my last post? This will confirm / deny accidental ADL as the cause. It is the next logical debugging step.
Thanks! S.C. Leung
Regards, Neil Groves [...]
No, where can I get the patch. Is it in the range_ex.zip? 2009/7/6 Neil Groves <neil@grovescomputing.com>
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung <shaochiliang@gmail.com> wrote:
Hello, Thorsten: Have you test my case and had the same problem with me? Does it mean that the library should call the function explicitly?
Did you try the patch for Boost.Algorithm that I supplied in my last post? This will confirm / deny accidental ADL as the cause.
It is the next logical debugging step.
Thanks! S.C. Leung
Regards, Neil Groves
[...]
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, Jul 6, 2009 at 5:42 PM, S.C. Leung <shaochiliang@gmail.com> wrote:
No, where can I get the patch. Is it in the range_ex.zip?
It's attached in this thread in a previous post. It's not a patch for range because range correctly has protection against accidental ADL. If the problem is accidental ADL the defect is in Boost.Algorithm. I, however, cannot explain how a std::string would cause an ADL problem internally within a boost namespace. I simply provided the file to eliminate or confirm Thorsten's hypothesis. I'll send the file again to you at your email address. It needs to replace <boost/algorithm/string/find.hpp>. Regards, Neil Groves
2009/7/6 Neil Groves <neil@grovescomputing.com>
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung <shaochiliang@gmail.com>wrote:
Hello, Thorsten: Have you test my case and had the same problem with me? Does it mean that the library should call the function explicitly?
Did you try the patch for Boost.Algorithm that I supplied in my last post? This will confirm / deny accidental ADL as the cause.
It is the next logical debugging step.
Thanks! S.C. Leung
Regards, Neil Groves
[...]
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
The patch of <boost/algorithm/string/find.hpp> did work. Then what's the conclusion? Could anyone reproduce my difficulty? Or it is just my missing something when using find_first with "boost/range/algorithm.hpp"? 2009/7/7 Neil Groves <neil@grovescomputing.com>
On Mon, Jul 6, 2009 at 5:42 PM, S.C. Leung <shaochiliang@gmail.com> wrote:
No, where can I get the patch. Is it in the range_ex.zip?
It's attached in this thread in a previous post. It's not a patch for range because range correctly has protection against accidental ADL. If the problem is accidental ADL the defect is in Boost.Algorithm. I, however, cannot explain how a std::string would cause an ADL problem internally within a boost namespace. I simply provided the file to eliminate or confirm Thorsten's hypothesis.
I'll send the file again to you at your email address. It needs to replace <boost/algorithm/string/find.hpp>.
Regards, Neil Groves
2009/7/6 Neil Groves <neil@grovescomputing.com>
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung <shaochiliang@gmail.com>wrote:
Hello, Thorsten: Have you test my case and had the same problem with me? Does it mean that the library should call the function explicitly?
Did you try the patch for Boost.Algorithm that I supplied in my last post? This will confirm / deny accidental ADL as the cause.
It is the next logical debugging step.
Thanks! S.C. Leung
Regards, Neil Groves
[...]
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, Jul 7, 2009 at 2:25 AM, S.C. Leung <shaochiliang@gmail.com> wrote:
The patch of <boost/algorithm/string/find.hpp> did work. Then what's the conclusion? Could anyone reproduce my difficulty? Or it is just my missing something when using find_first with "boost/range/algorithm.hpp"?
The conclusion is that this problem is a defect in Boost.Algorithm. This library suffers from unprotected accidental ADL. I am about to request that this is fixed, or that I am given access to fix the problem. Thank you for your patience and assistance with this issue. Best wishes, Neil Groves [...]
participants (3)
-
Neil Groves -
S.C. Leung -
Thorsten Ottosen -
梁绍池