This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Self move assignment debug check
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 10 Nov 2015 13:13:55 +0000
- Subject: Re: Self move assignment debug check
- Authentication-results: sourceware.org; auth=none
- References: <55F71189 dot 8080006 at gmail dot com> <20150914195038 dot GQ2631 at redhat dot com> <55F9C4F6 dot 6030706 at gmail dot com> <20150916202953 dot GE2631 at redhat dot com> <5637CA97 dot 8060404 at gmail dot com>
On 02/11/15 21:41 +0100, François Dumont wrote:
On 16/09/2015 22:29, Jonathan Wakely wrote:
On 16/09/15 21:37 +0200, François Dumont wrote:
On 14/09/2015 21:50, Jonathan Wakely wrote:
On 14/09/15 20:27 +0200, François Dumont wrote:
diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index 305d446..89a9aec 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -449,6 +449,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
vector&
operator=(vector&& __x)
noexcept(_Alloc_traits::_S_nothrow_move())
{
+ __glibcxx_assert(this != &__x);
Please don't do this, it fails in valid programs. The standard needs
to be fixed in this regard.
The debug mode check should be removed too then.
Yes.
I had a look to the code of several move assignment operators. If
the plan is that it should be a no-op then they are not supporting
operation with self. Do you mean that those operators should be made
compatible so that debug check can be removed ?
If so the simplest evolution would be to add:
if (this == &__x)
return *this;
Is it how the Standard is going to be adapted ?
The most likely change will be to say that the effect is unspecified,
rather than undefined. That means we can't abort, but as long as we
don't leak and respect the basic exception-safety guarantee, we're OK.
So for example for containerrs it's OK if the container ends up empty,
but it's not OK if it leaks memory or leads to a double-free.