Re: Class invariants and implicit move constructors (C++0x)
* Scott Meyers, on 15.08.2010 06:07:
Consider a class with two containers, where the sum of the sizes of the
containers is cached. The class invariant is that as long as the cache
is claimed to be up to date, the sum of the sizes of the containers is
accurately cached:
class Widget {
public:
...
private:
std::vector<int> v1;
std::vector<int> v2;
mutable std::size_t cachedSumOfSizes;
mutable bool cacheIsUpToDate;
void checkInvariant() const
{ assert(!cacheIsUpToDate || cachedSumOfSizes == v1.size()+v2.size()); }
};
Assume that checkInvariant is called at the beginning and end of every
public member function. Further assume that the class declares no copy
or more operations, i.e., no copy or move constructor, no copy or move
assignment operator.
Suppose I have an object w where v1 and v2 have nonzero sizes, and
cacheIsUpToDate is true. Hence cachedSumOfSizes == v1.size()+v2.size().
If w is copied, the compiler-generated copy operation will be fine, in
the sense that w's invariant will remain fulfilled. After all, copying w
does not change it in any way.
But if w is moved, the compiler-generated move operation will "steal"
v1's and v2's contents, setting their sizes to zero. That same
compiler-generated move operation will copy cachedSumOfSizes and
cacheIsUpToDate (because moving built-in types is the same as copying
them), and as a result, w will be left with its invariant unsatisfied:
v1.size()+v2.size() will be zero, but cachedSumOfSizes won't be, and
cacheIsUpToDate will remain true.
When w is destroyed, the assert inside checkInvariant will fire when
it's called from w's destructor. That means that the compiler-generated
move operation for Widget broke the Widget invariant, even though the
compiler-generated copy operations for Widget left it intact.
The above scenario suggests that compiler-generated move operations may
be unsafe even when the corresponding compiler-generated copy operations
are safe. Is this a valid analysis?
As far as it goes, it seems so, yes, at least wrt. n3090 which is the draft I have.
A move from an object X leaves X as zombie where there's logically nothing left
to destroy, and class needs to be designed to deal with it, in order to deal
properly with it.
And so, given that & my general wait-n-see ignorance of C++0x, I'm surprised to
hear that a move constructor is implicitly generated (n3090 ?12.8/10). It breaks
existing code. It should not have been done.
HOWEVER, it does not seem to be a problem with actual compilers for Windows.
A simpler example than yours, with explicitly declared move constructor:
<code>
#include <assert.h>
#include <string>
#include <iostream>
class Blah
{
private:
std::string blah;
public:
Blah(): blah( "blah" ) {}
Blah( Blah&& other ): blah( std::move( other.blah ) )
{
std::cout << "[" << other.blah << "]" << std::endl;
}
~Blah() { assert( blah == "blah" ); }
};
void foo( Blah&& a )
{
Blah* p = new Blah( std::move( a ) );
delete p;
}
int main()
{
foo( Blah() );
}
</code>
<example>
C:\test> g++ --version
g++ (TDM-2 mingw32) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\test> g++ -std=c++0x x.cpp
C:\test> a
[blah]
C:\test> cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\test> cl /nologo /EHsc /GR /Zc:forScope,wchar_t x.cpp
x.cpp
C:\test> x
[]
Assertion failed: blah == "blah", file x.cpp, line 15
C:\test> _
</example>
From the above, evidently MSVC 10.0 implements move constructors, while g++
4.4.1 does not, or it doesn't have an optimized std::string.
But when the move constructor definition is commented out, the assert does not
kick in, indicating that a move constructor is not automatically generated:
<example>
C:\test> cl /nologo /EHsc /GR /Zc:forScope,wchar_t x.cpp
x.cpp
C:\test> x
C:\test> _
</example>
So perhaps the standard could just be amended to reflect current practice? <g>
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>