RE: [boost] checked_delete.hpp fix
> -Original Message- > From: David Abrahams [mailto:[EMAIL PROTECTED] > > Hmm, I don't recall that one. Care to refresh my memory? ;-) > Maybe they're the same discussion... > Yes, that was the discussion, and I apparently remembered things incorrectly. Thanks for the refresher. Jason Shirk VC++ Compiler Team ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Jason Shirk <[EMAIL PROTECTED]> writes: > From: David Abrahams >>> Hum, it looks like Microsoft took you up on it. >> >>Well, it was MS I was haranguing most-loudly about it. > > I don't recall a discussion on warnings about ADL, I'll need a > refresher. I remember mentioning it to you in Herb's car, among other places. Does that help? It is an attempt to find unqualified calls to functions which really should've been qualified (the author didn't intend ADL to be used). The ones my heuristic will warn about are those which don't happen to use ADL in the author's tests but might unintentionally use ADL in the field with bad results. The other part of the equation, of course, is that we'll also want two #pragmas: One we can use to label a function as a customization point, and suppresses the warning for calls that resolve to this function. Another we can use to label a function call as a customization point, and suppresses the warning for that call. Could be the same #pragma, I guess. > I do recall a discussion we had on non-dependent names. Hmm, I don't recall that one. Care to refresh my memory? ;-) Maybe they're the same discussion... -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] checked_delete.hpp fix
From: David Abrahams Hum, it looks like Microsoft took you up on it. >>Well, it was MS I was haranguing most-loudly about it. I don't recall a discussion on warnings about ADL, I'll need a refresher. I do recall a discussion we had on non-dependent names. >> See the shared_ptr_test warning on the VC++ 7.1 beta regression>> test.>>I've seen that. It's a different warning IIUC. Doesn't it go off>whether or not you find the overload in the same namespace the search>started from? The warning we added in VC7.1 was purely to diagnose behavior changes due to the implementation of ADL on ordinary function calls. I can't think of a scenario where it would warn as you suggest. Jason Shirk VC++ Compiler Team ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Peter Dimov wrote: > > Your example works for me. Qualified identifiers such as > boost::checked_delete disable ADL, and foo::boost::checked_delete isn't > found. I wasn't aware of this, so I assume that this is the standard's way of handling it and not just some compilers. Thanks. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Daniel Frey wrote:
> I wasn't thinking of the user to drop things into boost, this is
> obvbiously not supported. I was thinking of this:
>
> namespace foo {
> namespace boost { // <-- Is this "allowed" by boost?
> template< typename T >
> void checked_delete( T* );
> }
>
> class A {};
> }
>
> foo::A* bar = new foo::A();
> ::boost::checked_deleter< A >()( bar );
Your example works for me. Qualified identifiers such as
boost::checked_delete disable ADL, and foo::boost::checked_delete isn't
found.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Peter Dimov wrote:
>
> Daniel Frey wrote:
> >
> > Any reason why you went for 'boost::' instead of '::boost::' for the
> > prefix? IMO only the latter expresses exactly what we want or do we
> > rely on user to never create sub-namespaces called 'boost'? Although
> > this is not very likely, we shouldn't place any restrictions on users
> > that are not needed.
>
> What we want is to disable ADL, any qualification does that. There's really
> no practical difference between boost:: and ::boost:: in this case; the user
> is not expected to just drop identifiers into boost and expect things to
> work. They won't. We aren't required to document all identifiers in boost,
> so we reserve the right to not compile if there is a collision.
I wasn't thinking of the user to drop things into boost, this is
obvbiously not supported. I was thinking of this:
namespace foo {
namespace boost { // <-- Is this "allowed" by boost?
template< typename T >
void checked_delete( T* );
}
class A {};
}
foo::A* bar = new foo::A();
::boost::checked_deleter< A >()( bar );
Regards, Daniel
--
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
"Peter Dimov" <[EMAIL PROTECTED]> writes: >> Hum, it looks like Microsoft took you up on it. See the >> shared_ptr_test warning on the VC++ 7.1 beta regression test. > > No, C4675 is the opposite of what Dave wants. Earlier MSVC didn't support > ADL at all, and MSVC 7.1 is now issuing the warning for every place ADL > kicks in since this may alter the behavior of existing code. Dave wants a > warning when ADL could have kicked in but didn't. Or rather, where it did kick in but it found nothing, so the fallback was the name in the local namespace. > Sounds like a neat plan to solicit _many_ user complaints. ;-) No kidding! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Beman Dawes <[EMAIL PROTECTED]> writes: > At 08:34 AM 2/25/2003, David Abrahams wrote: > > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> Go ahead and make the change, unless someone voices an objection. > >> > >> I'm wondering how may other places we have similar problems? > > > >Now you know why I've been making such a stink about insidious ADL! > > > >> Is there any programatic way to detect them? > > > >I've been trying to get compiler vendors to add a warning for names to > >which ADL applies but which are found in the local namespace. This, > >at least, would give us a way to detect likely candidates. No takers > >yet :(. > > Hum, it looks like Microsoft took you up on it. Well, it was MS I was haranguing most-loudly about it. > See the shared_ptr_test warning on the VC++ 7.1 beta regression > test. I've seen that. It's a different warning IIUC. Doesn't it go off whether or not you find the overload in the same namespace the search started from? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Daniel Frey wrote: > > Any reason why you went for 'boost::' instead of '::boost::' for the > prefix? IMO only the latter expresses exactly what we want or do we > rely on user to never create sub-namespaces called 'boost'? Although > this is not very likely, we shouldn't place any restrictions on users > that are not needed. What we want is to disable ADL, any qualification does that. There's really no practical difference between boost:: and ::boost:: in this case; the user is not expected to just drop identifiers into boost and expect things to work. They won't. We aren't required to document all identifiers in boost, so we reserve the right to not compile if there is a collision. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Beman Dawes wrote: > At 08:34 AM 2/25/2003, David Abrahams wrote: > > >Beman Dawes <[EMAIL PROTECTED]> writes: > > > >> Go ahead and make the change, unless someone voices an objection. > >> > >> I'm wondering how may other places we have similar problems? > > > >Now you know why I've been making such a stink about insidious ADL! "I told you so!" ;-) > >> Is there any programatic way to detect them? > > > >I've been trying to get compiler vendors to add a warning for names > to >which ADL applies but which are found in the local namespace. > This, >at least, would give us a way to detect likely candidates. > No takers >yet :(. > > Hum, it looks like Microsoft took you up on it. See the > shared_ptr_test warning on the VC++ 7.1 beta regression test. No, C4675 is the opposite of what Dave wants. Earlier MSVC didn't support ADL at all, and MSVC 7.1 is now issuing the warning for every place ADL kicks in since this may alter the behavior of existing code. Dave wants a warning when ADL could have kicked in but didn't. Sounds like a neat plan to solicit _many_ user complaints. ;-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Peter Dimov wrote: > > Daniel Frey wrote: > > Hi, > > > > I came across the following problem: > > > > When I have a class X which lives in a namespace where there's a > > function 'checked_delete' declared that can take a X*, smart_ptr (and > > probably others) that use checked_deleter (note the 'r'!) cannot call > > checked_delete. It's ambiguous due to argument dependent lookup. > > Fixed, thanks. Any reason why you went for 'boost::' instead of '::boost::' for the prefix? IMO only the latter expresses exactly what we want or do we rely on user to never create sub-namespaces called 'boost'? Although this is not very likely, we shouldn't place any restrictions on users that are not needed. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
At 08:34 AM 2/25/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> Go ahead and make the change, unless someone voices an objection. >> >> I'm wondering how may other places we have similar problems? > >Now you know why I've been making such a stink about insidious ADL! > >> Is there any programatic way to detect them? > >I've been trying to get compiler vendors to add a warning for names to >which ADL applies but which are found in the local namespace. This, >at least, would give us a way to detect likely candidates. No takers >yet :(. Hum, it looks like Microsoft took you up on it. See the shared_ptr_test warning on the VC++ 7.1 beta regression test. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Beman Dawes <[EMAIL PROTECTED]> writes: > Go ahead and make the change, unless someone voices an objection. > > I'm wondering how may other places we have similar problems? Now you know why I've been making such a stink about insidious ADL! > Is there any programatic way to detect them? I've been trying to get compiler vendors to add a warning for names to which ADL applies but which are found in the local namespace. This, at least, would give us a way to detect likely candidates. No takers yet :(. I wonder if a tool like GCC_XML could be of help? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Beman Dawes wrote: [about inintended ADL] > I'm wondering how may other places we have similar problems? Many. ;-) > Is there any programatic way to detect them? I don't think there is, but even if there was, I'd suggest leaving things as they currently are, and waiting for the actual problem reports before preemptively fixing anything. This will give us valuable information about the scope of the so-called "ADL problem". ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Daniel Frey wrote: > Hi, > > I came across the following problem: > > When I have a class X which lives in a namespace where there's a > function 'checked_delete' declared that can take a X*, smart_ptr (and > probably others) that use checked_deleter (note the 'r'!) cannot call > checked_delete. It's ambiguous due to argument dependent lookup. Fixed, thanks. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
At 07:32 PM 2/24/2003, Daniel Frey wrote:
>Hi,
>
>I came across the following problem:
>
>When I have a class X which lives in a namespace where there's a function
>'checked_delete' declared that can take a X*, smart_ptr (and probably
>others)
>that use checked_deleter (note the 'r'!) cannot call checked_delete. It's
>ambiguous due to argument dependent lookup. To fix it, I had to make the
>call to checked_delete in checked_deleter qualified:
>
>template struct checked_deleter
>{
>typedef void result_type;
>typedef T * argument_type;
>
>void operator()(T * x) const
>{
>::boost::checked_delete(x);
>}
>};
>
>(alas for checked_array_deleter)
>
>Comments?
Go ahead and make the change, unless someone voices an objection.
I'm wondering how may other places we have similar problems?
Is there any programatic way to detect them?
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] checked_delete.hpp fix
Daniel Frey <[EMAIL PROTECTED]> writes:
> When I have a class X which lives in a namespace where there's a function
> 'checked_delete' declared that can take a X*, smart_ptr (and probably others)
> that use checked_deleter (note the 'r'!) cannot call checked_delete. It's
> ambiguous due to argument dependent lookup. To fix it, I had to make the
> call to checked_delete in checked_deleter qualified:
>
> template struct checked_deleter
> {
> typedef void result_type;
> typedef T * argument_type;
>
> void operator()(T * x) const
> {
> ::boost::checked_delete(x);
> }
> };
>
> (alas for checked_array_deleter)
>
> Comments?
ADL strikes again!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] checked_delete.hpp fix
Hi,
I came across the following problem:
When I have a class X which lives in a namespace where there's a function
'checked_delete' declared that can take a X*, smart_ptr (and probably others)
that use checked_deleter (note the 'r'!) cannot call checked_delete. It's
ambiguous due to argument dependent lookup. To fix it, I had to make the
call to checked_delete in checked_deleter qualified:
template struct checked_deleter
{
typedef void result_type;
typedef T * argument_type;
void operator()(T * x) const
{
::boost::checked_delete(x);
}
};
(alas for checked_array_deleter)
Comments?
Regards, Daniel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
