[Range.Ex / String.Algo] Ambiguous call to overload function "find"

newer
[Asio]How to peocess signal with...

older
[Signals2] Compile error saying...

梁绍池

3 Jul 2009 3 Jul '09

1:38 a.m.

I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include #include 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

Attachments:

attachment.html (text/html — 1.0 KB)

Show replies by date

Neil Groves

3 Jul 3 Jul

9:57 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

Hello! On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 wrote:

...

I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include #include

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

S.C. Leung

4:53 p.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

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

...

Hello!

On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 wrote:

...
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include #include

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

Neil Groves

5 Jul 5 Jul

11:04 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

2009/7/3 S.C. Leung

...

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

...
Hello!

On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 wrote:

...
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include #include

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

S.C. Leung

6 Jul 6 Jul

2:56 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

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

...

2009/7/3 S.C. Leung

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

...
Hello!

On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 wrote:

...
I use vc 9.0 to compile the following code with boost 1.39.0 and range_ex. #include<string> #include #include

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

Thorsten Ottosen

9:14 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

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

S.C. Leung

2:22 p.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

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

...

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

Neil Groves

2:57 p.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung 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 [...]

S.C. Leung

4:42 p.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

No, where can I get the patch. Is it in the range_ex.zip? 2009/7/6 Neil Groves

...

On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung 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

Neil Groves

5:14 p.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

On Mon, Jul 6, 2009 at 5:42 PM, S.C. Leung 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 . Regards, Neil Groves

...

2009/7/6 Neil Groves

...
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung 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

S.C. Leung

7 Jul 7 Jul

1:25 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

The patch of 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

...

On Mon, Jul 6, 2009 at 5:42 PM, S.C. Leung 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 .

Regards, Neil Groves

...
2009/7/6 Neil Groves

...
On Mon, Jul 6, 2009 at 3:22 PM, S.C. Leung 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

Neil Groves

7:34 a.m.

New subject: [Range.Ex / String.Algo] Ambiguous call to overload function "find"

On Tue, Jul 7, 2009 at 2:25 AM, S.C. Leung wrote:

...

The patch of 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 [...]

5710

Age (days ago)

5714

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Neil Groves
S.C. Leung
Thorsten Ottosen
梁绍池