"Eric Niebler" wrote in message news:422CEAE9.3020708@boost-consulting.com... | Thorsten Ottosen wrote: | > My suggestion have been to allow | > | > boost::some_range_fun(r); | > | > to support ADL via the requirement that users implement | > | > adl_some_range_fun(r); | > | > Can you confirm that this would remove the present problems with gcc? | > | > If so, I will propose this on the developer list and make it part of 1.33 | > | | | I admit I've only skimmed the ongoing discussion, but something like | what you are suggesting here should work, I think. How about this: | | namespace boost { | | namespace range_detail_ { | | template<typename T> | typename range_iterator<T>::type boost_range_begin(T& t) { | // ... | } | | template<typename T> | typename range_iterator<T>::type begin(T& t) { | // this uses ADL | return boost_range_begin(t) | } | | } // namespace range_detail_ | | using range_detail_::begin; | | } how this is exactly implemented in boost.range is of minor concern to me; I'm after the protocol. | | Recommended practice would be to always use qualified calls to | boost::begin, yes. | and then let users define overloads of boost_range_begin | in their own namespace and let ADL find it. yes, except I was suggesting to call it adl_begin(). | Does that satisfy everybody's concerns? (Probably not, but it couldn't | hurt to ask, right?) no, it couldn't hurt. -Thorsten

"David Abrahams" wrote in message news:uis42sxdl.fsf@boost-consulting.com... | "Thorsten Ottosen" writes: | > Can you confirm that this would remove the present problems with gcc? | | I seriously doubt it. The problem is that GCC looks up all names the | same way, even if they're not functions. The only cure is for clients | to isolate types from one another in separate sub-namespaces, and but we will have boost::end() and boost::mpl::end<>. Shouldn't that be enough? The problem before was unqualified calls to end() as I understood it. That will not be needed for ADL to kick in anymore. -Thorsten

"David Abrahams" wrote in message news:usm36p768.fsf@boost-consulting.com... | "Thorsten Ottosen" writes: | > but we will have boost::end() and boost::mpl::end<>. Shouldn't that be enough? | > | > The problem before was unqualified calls to end() as I understood it. That | > will not | > be needed for ADL to kick in anymore. | | Weren't you going to have boost::end() find the user's end via ADL? no, I was going to find user's adl_end() function via ADL. So this changes the extension protocol to overloading adl_end() from overloading end(). -Thorsten

"Arkadiy Vertleyb" wrote in message news:d0kplu$beq$1@sea.gmane.org... | "Thorsten Ottosen" wrote | | > | Weren't you going to have boost::end() find the user's end via ADL? | > | > no, I was going to find user's adl_end() function via ADL. So this changes | the | > extension protocol | > to overloading adl_end() from overloading end(). | | Then you are back to pre-namespace techniques :-) that would be another consequence; the primary reason is however that it is needed to allow qualified ADL without infinite recursion. | I most likely missed it from the discussion, but what's wrong with allowing | the user to overload boost::end() for her type? he still can, be he probably won't be able to in C++Ox, so we need another meachanism. If there are not templates involved, a function specialization is also possible. -Thorsten

"Thorsten Ottosen" writes:

"David Abrahams" wrote in message news:usm36p768.fsf@boost-consulting.com... | "Thorsten Ottosen" writes:

| > but we will have boost::end() and boost::mpl::end<>. Shouldn't that be enough? | > | > The problem before was unqualified calls to end() as I understood it. That | > will not | > be needed for ADL to kick in anymore. | | Weren't you going to have boost::end() find the user's end via ADL?

no, I was going to find user's adl_end() function via ADL. So this changes the extension protocol to overloading adl_end() from overloading end().

So, how does that keep ADL from kicking in? It doesn't. I guess the ugly adl_ prefix might protect you from most accidental collisions, but I'd rather see something that couldn't end up being a useful acronym in some other context http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=adl&Find=Find adl_end seems very likely to collide. acoustic-delay-line-ly y'rs, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

Thorsten Ottosen wrote:

"David Abrahams" wrote in message news:usm35lvo0.fsf@boost-consulting.com...

...

I guess the ugly adl_ prefix

do you now anything less ugly? It clearly states the purpose of the function.

Both begin() and range_begin() are much less ugly. adl_ as a prefix doesn't save you from colliding with another ADL customization point, if your convention catches on. It only saves you from g++. It's sad that one broken compiler has the power to make our interfaces ugly. Most other offenders only made the implementation ugly. And g++ will likely stay that way. If I had more free time I'd get mad.

Thorsten Ottosen wrote:

"Peter Dimov" wrote in message news:019001c5242b$3e480c70$6501a8c0@pdimov2...

...

adl_ as a prefix doesn't save you from colliding with another ADL customization point, if your convention catches on.

no, but is that relevant?

Probably not, if you're only interested in avoiding g++ specific collisions with mpl::begin.

"Thorsten Ottosen" writes:

"David Abrahams" wrote in message news:usm35lvo0.fsf@boost-consulting.com... | "Thorsten Ottosen" writes:

| > no, I was going to find user's adl_end() function via ADL. So this changes the | > extension protocol | > to overloading adl_end() from overloading end(). | | So, how does that keep ADL from kicking in? It doesn't.

no, we want ADL to kick in.

| I guess the ugly adl_ prefix

do you now anything less ugly? It clearly states the purpose of the function.

| might protect you from most accidental | collisions, but I'd rather see something that couldn't end up being a | useful acronym in some other context | | http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=adl&Find=Find | | adl_end seems very likely to collide.

does it?

Yes.

there is always some suffix, like _end(), _begin(), _size(), _empty().

You don't think someone might name a function to get the end of an analog delay line "adl_end?" You're much safer using boost_range_end or range_end if you're trying to keep it small. I don't see any reason to keep it small, though: users won't be invoking that function directly. -- Dave Abrahams Boost Consulting www.boost-consulting.com