Neil Groves wrote:
> You might get a quicker response from the GCC team, but I'm happy to look
> into this issue if you provide the exact version of GCC and library version
> you are using. It will, of course, take me a while since I'll have to setup
> the compiler and environment.
>
> You might want to take a look at the relevant standard library, or the
> compiler implementation of the new 'for' syntax. I suspect there might be an
> unqualified call to begin() and/or end().
For this issue, there is some information in the following thread:
(a patch and a test case are also provided in the thread.)
http://article.gmane.org/gmane.comp.lib.boost.devel/211863
If we are allowed to break existing codes that rely on ADL to find
boost::begin/end,
this issue can be easily resolved by putting boost::begin/end into an
ADL-barrier namespace
and bringing them into namespace boost with a using directive.
None of our boost code should be using unqualified calls to begin/end. The Boost.Range design explicitly provided range_begin and range_end as the function names to be found via ADL so that everyone could use qualified boost::begin and boost::end calls. boost::begin and boost::end are explicitly qualified throughout Boost.Range and hence the ambiguous call isn't coming from Boost.Range. Please see
http://www.boost.org/doc/libs/1_45_0/libs/range/doc/html/range/reference/extending/method_2.html for the relevant documentation.
Hence we can certainly break code that is erroneously relying on ADL for begin/end to be found via ADL.
However in this case I have yet to understand the nature of the underlying problem, because there isn't an obvious unqualified call to begin/end. The reverse adaptor uses qualified calls that can't possibly be ambiguous with std::begin/end. I haven't yet checked to see if unqualified calls to begin/end are intended to be used as an extension mechanism for the next C++ standard.
I shall put begin and end in an ADL barrier namespace anyhow, since these are explicitly designed to be qualified when called.