5

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?

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • That it might happen more than once? Isn't that just a facet of the general problem of assigning virtual bases? – Kerrek SB Jun 22 '13 at 17:14
  • @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. – Johannes Schaub - litb Jun 22 '13 at 17:20
  • 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"? – kfsone Jun 22 '13 at 18:26
  • @kfsone 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. – Johannes Schaub - litb Jun 22 '13 at 20:02

1 Answers1

4

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.

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577