Gwarantowane unikanie kopiowania dla jednolitej inicjalizacji tablicy stężonej - czy nie powinno to być obowiązkowe od C ++ 17? [duplikować]

Dec 06 2020

O ile dobrze rozumiem nowe zasady

https://en.cppreference.com/w/cpp/language/copy_elision

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html

Ten kod powinien zostać skompilowany dla kompilatorów zgodnych ze standardem C ++ 17

struct NonTrivialClass
{
    ~NonTrivialClass( ){  }
};

class MainNonTrivialClass 
{
public:
  MainNonTrivialClass(int t) : m_simpleTypeMember(t) { }
 
  virtual void makeMySelfNonTrivial() {}

  MainNonTrivialClass( const MainNonTrivialClass& other) = delete;
  MainNonTrivialClass& operator=( const MainNonTrivialClass& other) = delete;
  MainNonTrivialClass(MainNonTrivialClass&& other) = delete;
  MainNonTrivialClass& operator=(MainNonTrivialClass&& other) = delete;
  
  NonTrivialClass m_nontrivialMember;
  int m_simpleTypeMember;
};

class ArrayContainer
{
public:
  ArrayContainer() : m_array{{1}, {2} } {}

private:
  MainNonTrivialClass m_array[2];
};


int main()
{
  ArrayContainer accContainer;
}

Ale gcc 9.1.0 z -std = c ++ 17 -O2 -Wall -pedantic mówi (zgodnie z całkowitym oczekiwaniem dla pre C ++ 17)

main.cpp: In constructor 'ArrayContainer::ArrayContainer()':
main.cpp:25:39: error: use of deleted function 'MainNonTrivialClass::MainNonTrivialClass(MainNonTrivialClass&&)'
   25 |   ArrayContainer() : m_array{{1}, {2} } {}
      |                                       ^
main.cpp:15:3: note: declared here
   15 |   MainNonTrivialClass(MainNonTrivialClass&& other) = delete;

Inicjalizacja jednolita tablicy w ten sposób jest definiowana jako inicjalizacja kopii elementarnej (?) I powinna prowadzić do elizji kopiowania, więc tak naprawdę nie rozumiem, co się tutaj właściwie dzieje. Wydaje się, że mają tu zastosowanie stare reguły sprzed C ++ 17. Kolejną ciekawostką jest to, że ten sam kod kompiluje się dobrze, jeśli usunę m_nontrivialMember z mojej klasy MainNonTrivialClass, ale nie powinien prowadzić do tego samego błędu kompilacji, a następnie zawsze, ponieważ przypadek braku kopiowania wymusza zawsze istnienie odpowiednich konstruktorów kopiowania / przenoszenia ?

Odpowiedzi

1 ecatmur Dec 06 2020 at 18:22

Powinno to również działać przed C ++ 17, gdzie ta składnia jest bezpośrednią inicjalizacją. Zobacz Jak zainicjować tablicę klas z usuniętym konstruktorem kopiującym (C ++ 11), który odnosi się do błędu GCC 63707 .