Po co kopiujemy?

Aby zrozumieć, dlaczego jest to dobry wzór, powinniśmy zbadać alternatywy, zarówno w C++03, jak i w C++11.

Mamy metodę C++03 z std::string const&:

struct S
{
  std::string data; 
  S(std::string const& str) : data(str)
  {}
};

W tym przypadku, zawsze będzie wykonywana pojedyncza kopia. Jeśli zbudujesz z surowego ciągu C, zostanie skonstruowany std::string, a następnie skopiowany ponownie: dwie alokacje.

Istnieje metoda C++03 polegająca na pobraniu odniesienia do std::string, a następnie zamianie go na lokalny std::string:

struct S
{
  std::string data; 
  S(std::string& str)
  {
    std::swap(data, str);
  }
};

Jest to wersja C++03 "semantyki move", a swap może być często zoptymalizowana, aby była bardzo tania (podobnie jak move). Należy go również analizować w kontekście:

S tmp("foo"); // illegal
std::string s("foo");
S tmp2(s); // legal

I zmusza cię do utworzenia nie-tymczasowego std::string, a następnie odrzucenia go. (Tymczasowe std::string nie może wiązać się z referencją non-const). Jednak tylko jeden przydział jest dokonywany. Wersja C++11 wymagałaby && i wymagałaby wywołania za pomocą std::move, lub tymczasowego: wymaga to wywołujący jawnie tworzy kopię poza wywołaniem i przenosi ją do funkcji lub konstruktora.

struct S
{
  std::string data; 
  S(std::string&& str): data(std::move(str))
  {}
};

Użycie:

S tmp("foo"); // legal
std::string s("foo");
S tmp2(std::move(s)); // legal

Następnie możemy wykonać pełną wersję C++11, która obsługuje zarówno copy jak i move:

struct S
{
  std::string data; 
  S(std::string const& str) : data(str) {} // lvalue const, copy
  S(std::string && str) : data(std::move(str)) {} // rvalue, move
};

Możemy następnie zbadać, jak to jest używane:

S tmp( "foo" ); // a temporary `std::string` is created, then moved into tmp.data

std::string bar("bar"); // bar is created
S tmp2( bar ); // bar is copied into tmp.data

std::string bar2("bar2"); // bar2 is created
S tmp3( std::move(bar2) ); // bar2 is moved into tmp.data

Jest całkiem jasne, że ta technika przeciążania 2 jest co najmniej tak samo skuteczna, jeśli nie bardziej, niż dwa powyższe style C++03. I 'll dub this 2-overload version the" most wersja optymalna.

Teraz zbadamy wersję take-by-copy:

struct S2 {
  std::string data;
  S2( std::string arg ):data(std::move(x)) {}
};

W każdym z tych scenariuszy:

S2 tmp( "foo" ); // a temporary `std::string` is created, moved into arg, then moved into S2::data

std::string bar("bar"); // bar is created
S2 tmp2( bar ); // bar is copied into arg, then moved into S2::data

std::string bar2("bar2"); // bar2 is created
S2 tmp3( std::move(bar2) ); // bar2 is moved into arg, then moved into S2::data

Jeśli porównasz tę wersję side-by-side z "najbardziej optymalną" wersją, zrobimy dokładnie jedną dodatkową move! Ani razu nie robimy dodatkowego copy.

Więc jeśli założymy, że move jest tania, ta wersja daje nam prawie taką samą wydajność jak najbardziej optymalna wersja, ale 2 razy mniej kodu.

A jeśli przyjmujesz powiedzmy 2 do 10 argumentów, redukcja kodu jest wykładnicza-2x razy mniejsza przy 1 argumencie, 4X przy 2, 8x przy 3, 16x przy 4, 1024x przy 10 argumentach.

Teraz możemy obejść to za pomocą perfect forwarding i SFINAE, pozwalając na napisanie pojedynczego konstruktora lub szablonu funkcji, który pobiera 10 argumentów, robi SFINAE, aby upewnić się, że argumenty są odpowiednich typów, a następnie przenosi-lub-kopiuje je do stanu lokalnego zgodnie z wymaganiami. Podczas gdy zapobiega to tysiąckrotnemu wzrostowi problemu wielkości programu, nadal może istnieć cały stos funkcji generowanych z tego szablonu. (instancje funkcji szablonu generują funkcje)

A wiele generowanych funkcji oznacza większy rozmiar kodu wykonywalnego, co samo w sobie może zmniejszyć wydajność.

Za cenę kilku moves otrzymujemy krótszy kod i prawie taką samą wydajność, a często łatwiejszy do zrozumienia kod.

Teraz to działa tylko dlatego, że wiemy, gdy funkcja (w tym przypadku konstruktor) jest wywoływana, że będzie chciał lokalnej kopii tego argumentu. Chodzi o to, że jeśli wiemy, że będziemy robić kopię, powinniśmy poinformować rozmówcę, że robimy kopię, umieszczając ją na naszej liście argumentów. Mogą wtedy zoptymalizować fakt, że dadzą nam kopię (na przykład przechodząc do naszego argumentu).

Kolejną zaletą techniki "take by value" jest to, że często konstruktory move są noexcept. Oznacza to funkcje, które przybierają wartość i wyprowadzają ich argument może być często noexcept, przenosząc dowolne throw s z ich ciała i do zakresu wywołującego (który może go uniknąć poprzez bezpośrednią budowę czasami, lub konstruować elementy i move do argumentu, aby kontrolować, gdzie się dzieje rzucanie). Dokonywanie metod nothrow jest często tego warte.

Jest to prawdopodobnie celowe i podobne do idiomu copy and swap. Zasadniczo ponieważ łańcuch jest kopiowany przed konstruktorem, sam konstruktor jest bezpieczny dla wyjątków, ponieważ tylko zamienia (przenosi) tymczasowy łańcuch str.

Nie chcesz się powtarzać pisząc konstruktor dla ruchu i jeden dla kopii:

S(std::string&& str) : data(std::move(str)) {}
S(const std::string& str) : data(str) {}

Jest to dużo kodu boilerplate, zwłaszcza jeśli masz wiele argumentów. Twoje rozwiązanie pozwala uniknąć powielania kosztów niepotrzebnego ruchu. (Operacja przeprowadzki powinna być jednak dość tania.)

Konkurencyjnym idiomem jest użycie perfect forwarding:

template <typename T>
S(T&& str) : data(std::forward<T>(str)) {}

Magia szablonu wybierze przeniesienie lub skopiowanie w zależności od parametru, który podasz. Informatyka zasadniczo rozszerza się do pierwszej wersji, gdzie oba konstruktory zostały napisane ręcznie. Aby uzyskać podstawowe informacje, Zobacz post Scotta Meyera na Universal references .

Z punktu widzenia wydajności, wersja perfect forwarding jest lepsza od twojej wersji, ponieważ pozwala uniknąć niepotrzebnych ruchów. Można jednak argumentować, że Twoja wersja jest łatwiejsza do czytania i pisania. Ewentualny wpływ na wydajność i tak nie powinien mieć znaczenia w większości sytuacji, więc wydaje się, że jest to kwestia stylu w koniec.