Reply to thread

Message

[QUOTE="Scott Meyers, post: 4116390"]
Moves don't leave objects in "a zombie state." They must leave objects in a 
state where their invariants are satisfied.  Note that not all objects being 
moved from will be destroyed immediately thereafter.  Consider:

std::thread t1([]{ doSomething(); };
   std::thread t2(std::move(t2));                    // move t2's state to t1

At this point, t1 has been moved from, but it still exists and can still be 
used.  It will be destroyed at the end of its scope, as usual, but until then, 
it can have any std::thread member function invoked on it.  I wouldn't call t1 a 
zombie, but I agree that whatever state it has, the class must be designed to 
deal with it.

I don't know of any compiler for Windows that implements the part of draft C++0x 
pertaining to the implicit generation of move operations, but many draft C++0x 
features are currently available in gcc 4.5 and MSVC 10.  Check out 
[URL]http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm[/URL] .

I think the fundamental problem here is that a copy operation, because it 
doesn't modify its source, can't invalidate a class invariant, but a move 
operation can.  Unless, of course, I'm overlooking something.

Scott
[/QUOTE]

Verification