views:

201

answers:

1

Why there is default move constructor or assignment operator not created for derived classes? To demonstrate what I mean; having this setup code:

#include <utility>

struct A
{
  A () { }
  A (A&&) { throw 0; }
  A& operator= (A&&) { throw 0; }
};

struct B : A
{ };

either of the following lines throws:

A  x (std::move (A ());
A  x;  x = A ();

but neither of the following does:

B  x (std::move (B ());
B  x;  x = B ();

In case it matters, I tested with GCC 4.4.

EDIT: Later test with GCC 4.5 showed the same behavior.

+6  A: 

Reading through 12.8 in the 0x FCD (12.8/17 in particular for the move ctor), this appears to be a GCC bug. I see the same thing happening in 4.5 as you do in 4.4.

I may be missing a corner case on deleted functions, or something similar, but I don't see any indication of that yet.

Roger Pate
Just tested with 4.5, I get the same results. Can you test on any other compiler? (Given that C++0x is in no way finished, it might be not a bug but rather an outdated behavior, by the way.)
doublep
A bunch of stuff in 12.8 (originating in N3053) isn't supported in `gcc` yet, according to their [C++0x support page](http://gcc.gnu.org/projects/cxx0x.html) - could this be the issue?
Mike Dinsdale
@Mike: Looks like it, yes.
Roger Pate
@douplep: If the goal is to support what the 0x FCD says, then it's a bug even if it originates from outdated behavior. :)
Roger Pate
@Roger: Yeah, probably you are right. I guess we can settle on your answer if anyone can verify that default move constructor/assignment is implicitly added on any other compiler.
doublep
@doublep: Why is it required that another compiler does it correctly, to say that GCC is not following the FCD?
Roger Pate
@Roger: Because I'm not smart enough to understand standard just like that ;)
doublep
@Roger: It turned out I had an outdated draft, so I didn't quite understand your answer. After reading the clause you mentioned in the current draft it is clear. Thank you.
doublep