"Arkadiy Vertleyb" wrote in message
news:d05g68$qqu$1@sea.gmane.org...
| "Eric Niebler" wrote
|
| > Jonathan Turkanis wrote:
| > > Arkadiy Vertleyb wrote:
| > >
| > >>In this particular case the Boost.Range needs to be fixed to avoid
| > >>unqualified calls, IMO.
| > >
| > > I believe Thorsten deliberately wanted to allow unqualified calls.
| >
| > Yes, Boost.Range is designed that way. It is an extensible design -- you
| > can range-ify your own type by defining your own begin() and end() and
| > letting ADL find them. So it seems there is no simple work-around for
| > GCC's bizarre ADL rules in this case. We'll need to think of something
| else.
|
| Well, then I hate to say this, but IMHO this is a problem in the Boost.Range
| design :-(
It is deliberate design. All generic code that uses boost.range should
use unqualified calls to enable ADL.
<aside>
It is possible to imagine alternative designs where
all calls to end(c) can be made qualified and still enable
ADL; however, it requires the unqulified call of another function
inside boost::end(c) , say adl_end(c), to enable ADL of that function.
</aside>
| I am not really that familiar with this library, but I assume it has to do
| with containers, correct? Assume the following usage (pseudocode)
|
| Range(std::vector > > )
|
| Now ADL will use std, boost, MyNamespace, boost::multi_index, and boost::mpl
| to find Range. There is absolutely no guarantee that it won't find
| conflicting functions :-(
I don't get this. Surely one of the functions would be a better match than
the others and hence called.
-Thorsten
