Danger with virtual base move assignment operators when they are now allowed to be used?

Question

This concerns the resolution of C++ Issue http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402 . Summary:

template<typename T>
struct wrap
{
   wrap() = default;

   wrap(wrap&&) = default;
   wrap(const wrap&) = default;

   T t;
};

struct S {
   S(){}
   S(const S&){}
   S(S&&){}
};

typedef wrap<const S> W;

// Error, defaulted move constructor of "wrap<const S>" is deleted!
W get() { return W(); }

(The issue is that we are getting an error for this snippet, even though the compiler could simply use the copy constructor of "S", as it does when the user explicitly writes the move constructor of "wrap". The issue was resolved to ignore deleted move constructors (and assignment operators) during overload resolutions, hence using the copy constructor above as desired.)

When the resolution was drafted, the following comment was made about this resolution:

There are no additional restrictions for implicit/defaulted move operations relative to copy. This means that move assignment in a virtual base is dangerous (and compilers should probably warn) [...] But we decided in Batavia that we weren't going to preserve all C++03 code against implicit move operations, and I think this resolution provides significant performance benefits.

Can someone please describe what the concern with virtual base move assignment operators is?

Asher

That it might happen more than once? Isn't that just a facet of the general problem of assigning virtual bases? – Karlin

@KerrekSB ah I had no idea that this is possible. Althought I am still not quite seeing the problem clearly. I would be glad if you could clarify when a problem can occur. – Asher

This compiles ok under gcc 4.7.3 with -std=c++11 -Wall; which compiler are you using? Could it simply be a compiler defect resulting from a misunderstanding of "user supplied" vs "user defined"? – Aegina

@Aegina I think the rule that the DR holds responsible for the rejection is "the type must have a move constructor". Interpreted literally, the testcase is indeed valid. But in fact, the intended interpretation appears "overload resolution for the constructor must select a move constructor". So while "const S" has a move constructor, doing overload resolution with "const S" as argument, we get the copy constructor as result. I don't think that GCC interprets it literalls (given that that DR's resolution was drafted by GCC's maintainer). Perhaps GCC just implements the resolution already. – Asher

Answer 1

Consider:

#include <iostream>

struct A
{
    A() = default;
    A(const A&) = default;
    A(A&&) = default;
    A& operator=(const A&) {std::cout << "operator=(const A&)\n"; return *this;}
    A& operator=(A&&) {std::cout << "operator=(A&&)\n"; return *this;}
};

struct B
    : virtual public A
{
};

struct C
    : virtual public A
{
};

struct D
    : public B,
      public C
{
};

int
main()
{
    D d1, d2;
    d1 = std::move(d2);
}

I believe this program should output:

operator=(A&&)
operator=(A&&)

For me it actually outputs:

operator=(const A&)
operator=(const A&)

But I think this is just a clang bug (compiled with -std=c++1y). If I am correct about what the output should be, then the danger is that the move assignment operator is called twice. This is harmless (though potentially expensive) with the copy assignment operator, but not with the move assignment operator.

Grandstand

Indeed, gcc 4.8.1 outputs "AA&" while clang++ 3.3 outputs "A&". – Tarentarentum

Yes, clang doesn't implement the resolution of DR1402 yet. When it does, it should give the output you propose, calling the move-assignment operator of the virtual base twice. – Milanmilanese