Hi, I've seen the following comment in noncopyable.hpp namespace noncopyable_ // protection from unintended ADL What does it mean protection from unintended ADL? Thanks, -- - Kobi
On 6/14/06, Kobi Cohen-Arazi <kobi.cohenarazi@gmail.com> wrote:
What does it mean protection from unintended ADL?
Using ADL, unqualified function names are looked up in the namespaces in which the arguments to the function are defined. Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up. Usually this isn't wanted, as noncopyable is an implementation detail, not an interface. ~ Scott McMurray
me22 <me22.ca@gmail.com> writes:
Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up.
Even if the derivation is private, as it should be for such an implementation detail? -- Steven E. Harris
On 6/14/06, Steven E. Harris <seh@panix.com> wrote:
me22 <me22.ca@gmail.com> writes:
Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up.
Even if the derivation is private, as it should be for such an implementation detail?
I'd hope not, but I don't actually know. Perhaps it's just being "better safe than sorry". It's possible that a problem was noticed on a compiler with faulty ADL or when someone did struct foo : boost::noncopyable { ... }; without thinking of the ADL implications. ~ Scott McMurray
On 6/14/06, me22 <me22.ca@gmail.com> wrote:
Perhaps it's just being "better safe than sorry". It's possible that a problem was noticed on a compiler with faulty ADL or when someone did struct foo : boost::noncopyable { ... }; without thinking of the ADL implications.
Whats wrong with that struct foo : boost::noncopyable { ... }; ? I assume that public inheritance will be a problem, or am I missing here something? -- - Kobi
On 6/14/06, Kobi Cohen-Arazi <kobi.cohenarazi@gmail.com> wrote:
On 6/14/06, me22 <me22.ca@gmail.com> wrote:
Perhaps it's just being "better safe than sorry". It's possible that a problem was noticed on a compiler with faulty ADL or when someone did struct foo : boost::noncopyable { ... }; without thinking of the ADL implications.
Whats wrong with that struct foo : boost::noncopyable { ... }; ? I assume that public inheritance will be a problem, or am I missing here something?
Nothing is "wrong" with it. However, the public inheritance would cause ADL to look in the boost namespace if it weren't for the fix under discussion. Since boost::noncopyable is a typedef for boost::noncopyable_::noncopyable, with the fix ADL includes the boost::noncopyable_ namespace instead of the boost one, which is not an issue since there are no functions defined in it. ~ Scott McMurray
On Jun 14, 2006, at 12:41 PM, me22 wrote:
On 6/14/06, Steven E. Harris <seh@panix.com> wrote:
me22 <me22.ca@gmail.com> writes:
Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up.
Even if the derivation is private, as it should be for such an implementation detail?
I'd hope not, but I don't actually know.
Yes, the namespace of private base classes are searched during ADL. Imho, private inheritance for implementation is more fragile than other means for this reason. That being said, as long as no functions ever get put into boost::noncopyable_, then no harm should be done. One also has to watch out for ADL in the namespaces of template arguments (another common accidental use of ADL). For example: std::vector<N::MyClass, M::MyAllocator> v; foo(v); // searches std, N, M -Howard
Howard Hinnant wrote:
One also has to watch out for ADL in the namespaces of template arguments (another common accidental use of ADL). For example:
std::vector<N::MyClass, M::MyAllocator> v;
foo(v); // searches std, N, M
One common problem of this kind is template< class T, class A = std::allocator<T> > class X; X<int> x; foo( x ); // searches std
Peter Dimov <pdimov@mmltd.net> writes:
One common problem of this kind is
template< class T, class A = std::allocator<T> > class X;
X<int> x;
foo( x ); // searches std
Given that this can be characterized as a problem, what's a "positive" example to illustrate the motivation for this rule? There must be something useful it's meant to enable. Or, rather, I hope there is. -- Steven E. Harris
On Jun 14, 2006, at 3:58 PM, Steven E. Harris wrote:
Peter Dimov <pdimov@mmltd.net> writes:
One common problem of this kind is
template< class T, class A = std::allocator<T> > class X;
X<int> x;
foo( x ); // searches std
Given that this can be characterized as a problem, what's a "positive" example to illustrate the motivation for this rule? There must be something useful it's meant to enable. Or, rather, I hope there is.
For example the standard might create I/O for pair: template <class T1, class T2> ostream& operator<<(ostream&, pair<T1, T2>); Then you might also want to get more specialized behavior for pair<MyNamespace::MyType, int> (in your own namespace). It would be nice if when pair<MyNamespace::MyType, int> was given to operator<< both namespace std and namespace MyNamespace were searched for viable overloads. -Howard
Howard Hinnant <hinnant@twcny.rr.com> writes:
It would be nice if when pair<MyNamespace::MyType, int> was given to operator<< both namespace std and namespace MyNamespace were searched for viable overloads.
Thank you for the explanation. Perhaps this is similar to the "where do I customize swap()?" question, but one could argue that this overload should live in the std namespace, where the least specialized template function was declared. After all, it's std::operator<<() that we're overloading, not MyNamespace::operator<<(). We're trying to introduce special behavior for a particular argument type, not change the basic protocol of the template function. -- Steven E. Harris
"Steven E. Harris" <seh@panix.com> writes:
Howard Hinnant <hinnant@twcny.rr.com> writes:
It would be nice if when pair<MyNamespace::MyType, int> was given to operator<< both namespace std and namespace MyNamespace were searched for viable overloads.
Thank you for the explanation.
Perhaps this is similar to the "where do I customize swap()?" question, but one could argue that this overload should live in the std namespace, where the least specialized template function was declared. After all, it's std::operator<<() that we're overloading, not MyNamespace::operator<<(). We're trying to introduce special behavior for a particular argument type, not change the basic protocol of the template function.
Yes, one might argue that. http://boost-consulting.com/writing/n1691.html -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Yes, one might argue that.
Thanks for doing so.
I read it, and it sounds sensible. How would you characterize the reaction thus far? -- Steven E. Harris
"Steven E. Harris" <seh@panix.com> writes:
David Abrahams <dave@boost-consulting.com> writes:
Yes, one might argue that.
Thanks for doing so.
I read it, and it sounds sensible. How would you characterize the reaction thus far?
Umm, well. Let's see. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1912.pdf, which breaks code and doesn't really solve the problems, has been given floor time in the evolution working group at least three times now. My proposal, which was first submitted in 2002, has never been given any serious consideration. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
My proposal, which was first submitted in 2002, has never been given any serious consideration.
Well, at least N1912 throws you a bone: ,---- | N1691 may remain a preferable solution to N1893 because it does not | break existing code. `---- If there are fewer costs with your proposal, it's hard to see why the author used "may" here. Picture the MadLibs version of this sentence: __[noun]__ /may/ remain a preferable solution to __[noun]__ because it does not __[egregious action clause]__. -- Steven E. Harris
"Steven E. Harris" <seh@panix.com> writes:
David Abrahams <dave@boost-consulting.com> writes:
My proposal, which was first submitted in 2002, has never been given any serious consideration.
Well, at least N1912 throws you a bone:
,---- | N1691 may remain a preferable solution to N1893 because it does not | break existing code. `----
If there are fewer costs with your proposal, it's hard to see why the author used "may" here. Picture the MadLibs version of this sentence:
__[noun]__ /may/ remain a preferable solution to __[noun]__ because it does not __[egregious action clause]__.
My proposal represents a much bigger change to the language, so I'm not sure "fewer costs" would be a reasonable way to characterize it. It's a fairly big hammer to hit the problem with: inside of the new "explicit" namespace you could sneak in any number of brand new and otherwise-incompatible language rules, e.g. allow perl code inside an explicit namespace ;-) OTOH, it's a big problem, and IMO warrants a big hammer. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 15 Jun 2006 18:01:20 -0400, David Abrahams <dave@boost-consulting.com> wrote:
My proposal represents a much bigger change to the language,
And even that is questionable. David's proposal isn't so "small" as it may appear at first, IMHO. And the syntax burden is enourmous.
so I'm not sure "fewer costs" would be a reasonable way to characterize it. It's a fairly big hammer to hit the problem with: inside of the new "explicit" namespace you could sneak in any number of brand new and otherwise-incompatible language rules, e.g. allow perl code inside an explicit namespace ;-)
So you'll remove regex?? Seriously, I find that your proposal is well thought out, clear and "natural". Is there anything we can do to claim attention on it? BTW, while reading it I noticed a few typos: * this practice worked reasonably well, and is still being used /effecively/ for preprocessor macros *unlikely to compile correctly if a prefix were /ommitted/ * (possibly) explicit namespace new_std:: Is the :: intended? The fact that the paper hasn't had much consideration surprises me.
From what I've come to know from electronic contacts with them, I guess Bjarne and Peter Dimov, just to cite two, would be quite favourable to it.
BTW, have you considered something like mutable swap using mutable swap; for unqualified using-declarations? I find the second quite expressive. --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 15 Jun 2006 18:01:20 -0400, David Abrahams <dave@boost-consulting.com> wrote:
My proposal represents a much bigger change to the language,
And even that is questionable. David's proposal isn't so "small" as it may appear at first, IMHO. And the syntax burden is enourmous.
?? David's? Do you mean Herb's?
so I'm not sure "fewer costs" would be a reasonable way to characterize it. It's a fairly big hammer to hit the problem with: inside of the new "explicit" namespace you could sneak in any number of brand new and otherwise-incompatible language rules, e.g. allow perl code inside an explicit namespace ;-)
So you'll remove regex??
From what? Sorry, but what _are_ you talking about?
Seriously, I find that your proposal is well thought out, clear and "natural". Is there anything we can do to claim attention on it?
Attend the next committee meeting. Get on the evolution group mailing list and discuss it there in the meantime. Submit the proposal for the mid-term mailing, and most especially for the pre-meeting mailing.
BTW, while reading it I noticed a few typos:
* this practice worked reasonably well, and is still being used /effecively/ for preprocessor macros
*unlikely to compile correctly if a prefix were /ommitted/
Thanks.
* (possibly) explicit namespace new_std:: Is the :: intended?
Yes.
The fact that the paper hasn't had much consideration surprises me. From what I've come to know from electronic contacts with them, I guess Bjarne and Peter Dimov, just to cite two, would be quite favourable to it.
You don't know Bjarne very well, then. And Peter Dimov has never been to a meeting, so I'm usually representing his point of view, not the other way around.
BTW, have you considered something like
mutable swap using mutable swap;
for unqualified using-declarations? I find the second quite expressive.
What does the mutable keyword add, and how is it semantically appropriate? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Fri, 16 Jun 2006 16:38:55 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 15 Jun 2006 18:01:20 -0400, David Abrahams <dave@boost-consulting.com> wrote:
My proposal represents a much bigger change to the language,
And even that is questionable. David's proposal isn't so "small" as it may appear at first, IMHO. And the syntax burden is enourmous.
?? David's? Do you mean Herb's?
Sorry, I thought the proposal was by Daveed (and not "David") Vandevoorde, because his name appears in the upper right corner of the first page. And the text talks about Herb in third person.
So you'll remove regex??
From what? Sorry, but what _are_ you talking about?
Keep your hair on, that was a quip, as you said one could directly use Perl ;)
Seriously, I find that your proposal is well thought out, clear and "natural". Is there anything we can do to claim attention on it?
Attend the next committee meeting. Get on the evolution group mailing list and discuss it there in the meantime. Submit the proposal for the mid-term mailing, and most especially for the pre-meeting mailing.
Attending the meeting is absolutely beyond me. Can one join the evolution group list anyway?
BTW, while reading it I noticed a few typos:
* this practice worked reasonably well, and is still being used /effecively/ for preprocessor macros
*unlikely to compile correctly if a prefix were /ommitted/
Thanks.
* (possibly) explicit namespace new_std:: Is the :: intended?
Yes.
Yes, it's intended? What's the difference with the other examples, where "::" doesn't appear?
The fact that the paper hasn't had much consideration surprises me. From what I've come to know from electronic contacts with them, I guess Bjarne and Peter Dimov, just to cite two, would be quite favourable to it.
You don't know Bjarne very well, then.
Very true, unfortunately.
And Peter Dimov has never been to a meeting, so I'm usually representing his point of view, not the other way around.
And I thought he was in the CWG :-(
BTW, have you considered something like
mutable swap using mutable swap;
for unqualified using-declarations? I find the second quite expressive.
What does the mutable keyword add, and how is it semantically appropriate?
Strictly speaking it adds nothing. It would "just" make the construct stand out more, and distinguishable at first sight from a normal using declaration. Mutable was just chosen among the available keywords as the one which more closely could suggest the idea of a function call which can mutate, "adapting" itself to the type of the arguments. Of course if we were totally free to choose words we would probably go for something like enable ADL on swap; Oh, I think I found another typo here (not sure what the fix is): "Since they are perfectly easy, and will unintended ADL will pass unnoticed through all but the most sadistic tests"... Sincerely, --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Fri, 16 Jun 2006 16:38:55 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Thu, 15 Jun 2006 18:01:20 -0400, David Abrahams <dave@boost-consulting.com> wrote:
My proposal represents a much bigger change to the language,
And even that is questionable. David's proposal isn't so "small" as it may appear at first, IMHO. And the syntax burden is enourmous.
?? David's? Do you mean Herb's?
Sorry, I thought the proposal was by Daveed (and not "David") Vandevoorde, because his name appears in the upper right corner of the first page. And the text talks about Herb in third person.
Oh, it is. I thought we were talking about a different paper. I'm not sure that Daveed's proposal has any more syntax burden than mine. After all, in my proposal you need to write something similar to enable ADL. Why do you think his proposal isn't so "small," anyway? If I get 1691, I'd probably also want Daveed's proposal.
So you'll remove regex??
From what? Sorry, but what _are_ you talking about?
Keep your hair on, that was a quip, as you said one could directly use Perl ;)
Sorry, I should have told you I was born with a terrible handicap: no sense of humor.
Seriously, I find that your proposal is well thought out, clear and "natural". Is there anything we can do to claim attention on it?
Attend the next committee meeting. Get on the evolution group mailing list and discuss it there in the meantime. Submit the proposal for the mid-term mailing, and most especially for the pre-meeting mailing.
Attending the meeting is absolutely beyond me. Can one join the evolution group list anyway?
Sometimes that can be arranged. You can send a request to Andy Koenig <ark@acm.org>; I think he's still the point of contact for the reflectors.
BTW, while reading it I noticed a few typos:
* this practice worked reasonably well, and is still being used /effecively/ for preprocessor macros
*unlikely to compile correctly if a prefix were /ommitted/
Thanks.
* (possibly) explicit namespace new_std:: Is the :: intended?
Yes.
Yes, it's intended? What's the difference with the other examples, where "::" doesn't appear?
I was mistaken; it's a leftover from the first version of the paper.
BTW, have you considered something like
mutable swap using mutable swap;
for unqualified using-declarations? I find the second quite expressive.
What does the mutable keyword add, and how is it semantically appropriate?
Strictly speaking it adds nothing. It would "just" make the construct stand out more, and distinguishable at first sight from a normal using declaration.
I don't think it really helps, and...
Mutable was just chosen among the available keywords as the one which more closely could suggest the idea of a function call which can mutate, "adapting" itself to the type of the arguments.
...that logic doesn't work for me. There's no mutation going on. For me the presence of mutable there just creates mental dissonance.
Oh, I think I found another typo here (not sure what the fix is):
"Since they are perfectly easy, and will unintended ADL will pass unnoticed through all but the most sadistic tests"...
Thanks. If I decide to resubmit it I'll apply these edits. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Sat, 17 Jun 2006 09:10:20 -0400, David Abrahams <dave@boost-consulting.com> wrote:
Gennaro Prota <gennaro_prota@yahoo.com> writes:
On Fri, 16 Jun 2006 16:38:55 -0400, David Abrahams <dave@boost-consulting.com> wrote: [...] not sure that Daveed's proposal has any more syntax burden than mine.
Yeah, please ignore my comment on this. I managed to completely misunderstand how the namespace() operator would be used.
After all, in my proposal you need to write something similar to enable ADL. Why do you think his proposal isn't so "small," anyway?
Well, I was considering not Daveed's proposal in isolation but its combination with Herb's restrictions. I should have said Herb/Daveed's.
If I get 1691, I'd probably also want Daveed's proposal.
Yes. I totally agree.
[...]
BTW, have you considered something like
mutable swap using mutable swap;
for unqualified using-declarations? I find the second quite expressive.
[...] Mutable was just chosen among the available keywords as the one which more closely could suggest the idea of a function call which can mutate, "adapting" itself to the type of the arguments.
...that logic doesn't work for me. There's no mutation going on. For me the presence of mutable there just creates mental dissonance.
I see, it could be just wrong perception on my part: as you know English is not my native language. What about using auto swap; instead? (Curiously that would be yet another use, together with std::vector<int> v; auto it= v.begin(); for a keyword considered practically useless :))
[...]
Thanks. If I decide to resubmit it I'll apply these edits.
Yes please, resubmit it. Though, once removed my misunderstanding, the other proposal looks sound too, I think the comparison can't but improve discussion and suggest new ideas or issues. BTW, I don't see anything in Daveed's paper which would allow ADL on a *name*, regardless of the number of parameters. Intuitively that would be something like namespace()::f; or namespace(...)::f; but it isn't mentioned. --Gennaro.
Gennaro Prota <gennaro_prota@yahoo.com> writes:
...that logic doesn't work for me. There's no mutation going on. For me the presence of mutable there just creates mental dissonance.
I see, it could be just wrong perception on my part: as you know English is not my native language. What about
using auto swap;
instead?
Why not using static swap; ?? Just kidding. I suppose auto has a little more resonance here than static does, but I guess I just don't see the point in adding a keyword there.
(Curiously that would be yet another use, together with
std::vector<int> v; auto it= v.begin();
for a keyword considered practically useless :))
Yes, hence my joke about static. The fact that static is overloaded in so many ways is not generally considered a good thing. Since "auto" happens to be underloaded, giving it one useful role is a good idea, but two?
[...]
Thanks. If I decide to resubmit it I'll apply these edits.
Yes please, resubmit it.
If you remind me before the pre-meeting mailing deadline, I will (mid-term mailings don't have much impact usually).
Though, once removed my misunderstanding, the other proposal looks sound too,
In what way? AFAICT it's a band-aid (TM) that doesn't address the root of the problem... except that it's not really a band-aid (TM), because it also injures by breaking code.
I think the comparison can't but improve discussion and suggest new ideas or issues. BTW, I don't see anything in Daveed's paper which would allow ADL on a *name*, regardless of the number of parameters. Intuitively that would be something like
namespace()::f;
or
namespace(...)::f;
but it isn't mentioned.
You'll have to talk to Daveed if you want a comment on that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Steven E. Harris" <seh@panix.com> writes:
I read it, and it sounds sensible. How would you characterize the reaction thus far?
Umm, well. Let's see. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1912.pdf, which breaks code and doesn't really solve the problems, has been given floor time in the evolution working group at least three times now.
You mean Herb's proposal, right?
My proposal, which was first submitted in 2002, has never been given any serious consideration.
FWIW, evolution gave full support to Herb with the caveat that the namespace() operator was also introduced to get the old behavior. -Thorsten
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
"Steven E. Harris" <seh@panix.com> writes:
I read it, and it sounds sensible. How would you characterize the reaction thus far?
Umm, well. Let's see. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1912.pdf, which breaks code and doesn't really solve the problems, has been given floor time in the evolution working group at least three times now.
You mean Herb's proposal, right?
Is the link not working for you? Yes, that paper.
My proposal, which was first submitted in 2002, has never been given any serious consideration.
FWIW, evolution gave full support to Herb with the caveat that the namespace() operator was also introduced to get the old behavior.
What?!?! The namespace() operator? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
David Abrahams wrote:
"Steven E. Harris" <seh@panix.com> writes:
I read it, and it sounds sensible. How would you characterize the reaction thus far?
Umm, well. Let's see. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1912.pdf, which breaks code and doesn't really solve the problems, has been given floor time in the evolution working group at least three times now.
You mean Herb's proposal, right?
Is the link not working for you? Yes, that paper.
Sorry, yes, I meant Herb's proposal.
My proposal, which was first submitted in 2002, has never been given any serious consideration.
FWIW, evolution gave full support to Herb with the caveat that the namespace() operator was also introduced to get the old behavior.
What?!?! The namespace() operator?
Oh, I guess you skip one meeting and you start forgetting these things. I reviewed Daveed's paper for him as it says in the closing notes, so I shouldn't be surprised. -- Dave Abrahams Boost Consulting www.boost-consulting.com
me22 wrote:
On 6/14/06, Steven E. Harris <seh@panix.com> wrote:
me22 <me22.ca@gmail.com> writes:
Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up.
Even if the derivation is private, as it should be for such an implementation detail?
Yes, even if the derivation is private. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Steven E. Harris" <seh@panix.com> writes:
me22 <me22.ca@gmail.com> writes:
Presumably if noncopyable were defined in namespace boost, then function calls involving classes deriving from noncopyable would get namespace boost added to the ADL scopes in which the function is looked up.
Even if the derivation is private, as it should be for such an implementation detail?
Yes. Lookup and access rights are orthogonal in C++. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (9)
-
David Abrahams -
Eric Niebler -
Gennaro Prota -
Howard Hinnant -
Kobi Cohen-Arazi -
me22 -
Peter Dimov -
Steven E. Harris -
Thorsten Ottosen