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
On 6/14/06, Steven E. Harris <seh@panix.com> wrote:
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, Kobi Cohen-Arazi <kobi.cohenarazi@gmail.com> wrote:
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:
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
On Jun 14, 2006, at 3:58 PM, Steven E. Harris wrote:
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:
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:
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:
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:
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 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.
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:
?? David's? Do you mean Herb's?
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.
Thanks.
* (possibly) explicit namespace new_std:: Is the :: intended?
Yes.
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.
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:
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 ;)
Attending the meeting is absolutely beyond me. Can one join the evolution group list anyway?
Yes, it's intended? What's the difference with the other examples, where "::" doesn't appear?
Very true, unfortunately.
And I thought he was in the CWG :-(
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:
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.
Sorry, I should have told you I was born with a terrible handicap: no sense of humor.
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.
I was mistaken; it's a leftover from the first version of the paper.
I don't think it really helps, and...
...that logic doesn't work for me. There's no mutation going on. For me the presence of mutable there just creates mental dissonance.
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:
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.
[...]
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:
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.
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?
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.
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:
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
David Abrahams <dave@boost-consulting.com> writes:
Sorry, yes, I meant Herb's proposal.
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
participants (9)
-
David Abrahams -
Eric Niebler -
Gennaro Prota -
Howard Hinnant -
Kobi Cohen-Arazi -
me22 -
Peter Dimov -
Steven E. Harris -
Thorsten Ottosen