[Boost-users] Re:[Foreach]TroubleiteratingoverBoost.MultiIndexcontainers
Thorsten, I admit that my understanding of the problem was too simplistic, and apologize for being judgmental. (although I still think ADL-based solutions should be avoided, if only because of the GCC issue. Or, the GCC support should not be claimed) Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:d0il8i$jns$1@sea.gmane.org... | Thorsten, | | I admit that my understanding of the problem was too simplistic, and | apologize for being judgmental. no apology needed; it's good to discuss things. | (although I still think ADL-based solutions should be avoided, if only | because of the GCC issue. Or, the GCC support should not be claimed) I am myself irritated by the need to say using namespace boost; some_range_fun( r ); if nothing else, then because it is not super portable in itself. 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 br -Thorsten
Thorsten Ottosen wrote:
I am myself irritated by the need to say
using namespace boost; some_range_fun( r );
if nothing else, then because it is not super portable in itself.
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; } Recommended practice would be to always use qualified calls to boost::begin, and then let users define overloads of boost_range_begin in their own namespace and let ADL find it. Does that satisfy everybody's concerns? (Probably not, but it couldn't hurt to ask, right?) -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> 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
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:d0il8i$jns$1@sea.gmane.org... | Thorsten, | | I admit that my understanding of the problem was too simplistic, and | apologize for being judgmental.
no apology needed; it's good to discuss things.
| (although I still think ADL-based solutions should be avoided, if only | because of the GCC issue. Or, the GCC support should not be claimed)
I am myself irritated by the need to say
using namespace boost; some_range_fun( r );
if nothing else, then because it is not super portable in itself.
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?
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 bring them into a usable common namespace via using-declarations :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uis42sxdl.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uis42sxdl.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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.
Weren't you going to have boost::end() find the user's end via ADL? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm36p768.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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
| 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
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote the
extension protocol to overloading adl_end() from overloading end().
Then you are back to pre-namespace techniques :-) I most likely missed it from the discussion, but what's wrong with allowing the user to overload boost::end() for her type? Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote in message news:d0kplu$beq$1@sea.gmane.org... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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
Arkadiy Vertleyb wrote:
I most likely missed it from the discussion, but what's wrong with allowing the user to overload boost::end() for her type?
Two-phase name lookup. boost::end overloads that come after the definition of a template that uses boost::end are not considered.
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm36p768.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm35lvo0.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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? there is always some suffix, like _end(), _begin(), _size(), _empty(). on top of that there must also be collision wrt. the number of parameters. -Thorsten
Thorsten Ottosen wrote:
"David Abrahams" <dave@boost-consulting.com> 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.
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:019001c5242b$3e480c70$6501a8c0@pdimov2... | Thorsten Ottosen wrote: | > "David Abrahams" <dave@boost-consulting.com> 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. well, the first is a no-no due to recursion. the second still don't suggest its a customization point. | 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? -Thorsten
Thorsten Ottosen wrote:
"Peter Dimov" <pdimov@mmltd.net> 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.
Peter Dimov wrote:
Thorsten Ottosen wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm35lvo0.fsf@boost-consulting.com...
I guess the ugly adl_ prefix
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.
I suggest ugly_gcc_workaround_begin(), etc. Jonathan
"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:usm35lvo0.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> 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
David Abrahams wrote:
"Thorsten Ottosen" writes:
"David Abrahams" wrote:
adl_end seems very likely to collide.
does it?
You don't think someone might name a function to get the end of an analog delay line "adl_end?"
Or you might want to iterate over the members of the Anti-Defamation League. Jonathan
participants (2)
-
Arkadiy Vertleyb -
David Abrahams -
Eric Niebler -
Jonathan Turkanis -
Peter Dimov -
Thorsten Ottosen