"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:d05g68$qqu$1@sea.gmane.org... | "Eric Niebler" <eric@boost-consulting.com> 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<MyNamespace::SomeTemplate<boost::multi-index<boost::mpl::v | ector> > > ) | | 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