10

In the following example gcc 7 gives a warning:

defaulted move assignment for 'B' calls a non-trivial move assignment operator for virtual base 'A' [-Wvirtual-move-assign]

if I create an std::tuple<B> object. Clang 5 doesn't report any problems. Also the problem goes away if vector is removed from Base. Example.

#include <tuple>
#include <vector>

class Base
{
public:
    virtual ~Base();
    std::vector<int> v;
};

class A : public Base
{
};

class B : public virtual A
{
};

int main()
{
    B *b = new B;
    B another{*b}; // <<<--- this compiles
    std::tuple<B> t; // <<<--- gives warning
}

Why does it happen in presence of std::tuple (and absence of move assignment) and what is the proper way to fix it if I need to keep such a hierarchy?

Dev Null
  • 4,731
  • 1
  • 30
  • 46

1 Answers1

13

The warning is unrelated to tuple, it is triggered by a move assignment of B. For instance, the following code generates the warning

B b;
B t;
t = std::move(b);

The gcc documentation explains the intent of the warning

-Wno-virtual-move-assign

Suppress warnings about inheriting from a virtual base with a non-trivial C++11 move assignment operator. This is dangerous because if the virtual base is reachable along more than one path, it is moved multiple times, which can mean both objects end up in the moved-from state. If the move assignment operator is written to avoid moving from a moved-from object, this warning can be disabled.

Here's an example that demonstrates the problem

struct Base
{
    Base() = default;
    Base& operator=(Base&&)
    {
        std::cout << __PRETTY_FUNCTION__ << '\n';
        return *this; 
    }
};

struct A : virtual Base {};

struct B : virtual Base {};

struct C : A, B {};

int main()
{
    C c;
    c = C();
}

This produces the output

Base& Base::operator=(Base&&)
Base& Base::operator=(Base&&)

showing that the single Base instance was moved assigned to twice, once by each move assignment operator of A and B. The second move assignment is from an already moved from object, which could cause the contents from the first move assignment to be overwritten.

Note that clang also generates a warning in my example, it's probably detecting that A is not reachable via two paths in your example and not emitting the warning.

The way to fix it is to implement move assignment operators for A and B that can detect that Base has been moved from and omit a second move assignment.

Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • the first part of the question was more like why presence of `std::tuple` triggers this warning as there's no move assignment outside of `std::tuple` (I clarified this in the question as well). – Dev Null Oct 06 '17 at 07:32
  • Also, even if move assignment operators are implemented in this manner, the warning will still be generated, right? – Dev Null Oct 06 '17 at 07:38
  • 1
    @DevNull There's a move assignment happening during the `tuple` construction, somewhere within the stdlib implementation. You should be able to prove this by creating a class with appropriate print statements; I can post an example later today, don't have time right now. I don't understand the question in the second comment, the warning is avoided if you implement move assignment operators for `A` & `B` in my example. – Praetorian Oct 06 '17 at 17:17
  • [this example](http://coliru.stacked-crooked.com/a/0035af4f56a85475) shows that there's no move-assignment inside of default-constructed `std::tuple`, in fact [another example](http://coliru.stacked-crooked.com/a/59e9860fc1689150) shows that a class embedded into a `tuple` doesn't have to be copy or move constructible. I don't understand why default constructed `std::tuple t` from the question has anything to do with `B::B(B&&)`. – Dev Null Oct 06 '17 at 22:09
  • @DevNull Then it's either an overzealous warning from gcc or their `tuple` implementation is referencing the move assignment operator even though the code paths exercised by the example never execute a call to that operator. It's difficult to say which without studying the implementation. And removing the `vector` eliminates the warning because none of the members of `Base` or `A` have non-trivial move assignments. – Praetorian Oct 08 '17 at 17:43