[Boost-users] [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

[Neil Groves]

Hello!

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]

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 <ne...@grovescomputing.com>

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Neil Groves]

2009/7/3 S.C. Leung <shaoch...@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 <ne...@grovescomputing.com>

Hello!

On Fri, Jul 3, 2009 at 2:38 AM, 梁绍池 <shaoch...@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#header.boost.algorithm.string.find_hpp

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]

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 <ne...@grovescomputing.com>

[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

[S.C. Leung]

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...@dezide.com>

[Neil Groves]

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

[S.C. Leung]

No, where can I get the patch. Is it in the range_ex.zip? 

2009/7/6 Neil Groves <ne...@grovescomputing.com>

[Neil Groves]

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

 

[S.C. Leung]

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 <ne...@grovescomputing.com>

[Neil Groves]

On Tue, Jul 7, 2009 at 2:25 AM, S.C. Leung <shaoch...@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

[...]