Niebezpieczeństwo z operatorami przypisania wirtualnego przenoszenia bazy, gdy są teraz dozwolone?

Dotyczy to rozwiązania problemu C ++http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402 . Streszczenie:

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(); }

(Problem polega na tym, że otrzymujemy błąd dla tego fragmentu, mimo że kompilator może po prostu użyć konstruktora kopiowania „S”, tak jak ma to miejsce, gdy użytkownik jawnie zapisuje konstruktor ruchu „wrap”. Problem został rozwiązany do ignoruj ​​usunięte konstruktory przenoszenia (i operatory przypisania) podczas rozdzielczości przeciążania, a zatem używając konstruktora kopiowania powyżej, jak to pożądane.)

Kiedy rozdzielczośćzostał zredagowany, powstał następujący komentarz o tej rozdzielczości:

Nie ma żadnych dodatkowych ograniczeń dla niejawnych / domyślnych operacji przenoszenia względem kopii. Oznacza to, że przypisanie przeniesienia w wirtualnej bazie jest niebezpieczne (a kompilatory prawdopodobnie powinny ostrzec) [...] Ale w Batavii zdecydowaliśmy, że nie będziemy zachowywać całego kodu C ++ 03 przeciwko niejawnym operacjom przenoszenia i myślę niniejsza rezolucja zapewnia znaczne korzyści w zakresie wydajności.

Czy ktoś może opisać, czym jest problem operatorów wirtualnego przenoszenia bazy?

questionAnswers(1)

yourAnswerToTheQuestion