Dlaczego miałbym kiedykolwiek używać push_back zamiast laborace_back?

Wektory C ++ 11 mają nową funkcję emplace_back. W przeciwieństwie do tego push_back, który polega na optymalizacji kompilatora w celu uniknięcia kopiowania, emplace_backwykorzystuje doskonałe przekazywanie, aby wysyłać argumenty bezpośrednio do konstruktora w celu utworzenia obiektu w miejscu. Wydaje mi się, że emplace_backwszystko push_backrobi, ale czasami zrobi to lepiej (ale nigdy gorzej).

Z jakiego powodu muszę skorzystać push_back?

Zastanawiałem się nad tym pytaniem przez ostatnie cztery lata. Doszedłem do wniosku, że w większości wyjaśnień dotyczących push_backkontra emplace_backbrakuje pełnego obrazu.

W zeszłym roku wygłosiłem prezentację na C ++ Now o Type Deduction w C ++ 14 . Zaczynam mówić o push_backvs. emplace_backo 13:49, ale są przydatne informacje, które dostarczają wcześniej pewnych dowodów potwierdzających.

Prawdziwa pierwotna różnica dotyczy konstruktorów niejawnych i jawnych. Rozważ przypadek, w którym mamy jeden argument, który chcemy przekazać do push_backlub emplace_back.

std::vector<T> v;
v.push_back(x);
v.emplace_back(x);

Po tym, jak kompilator optymalizacyjny weźmie to pod uwagę, nie ma różnicy między tymi dwiema instrukcjami pod względem generowanego kodu. Tradycyjna mądrość polega na tym, push_backże skonstruuje tymczasowy obiekt, do którego zostanie następnie przeniesiony, vpodczas gdy emplace_backprzekaże dalej argument i skonstruuje go bezpośrednio w miejscu, bez kopii lub ruchów. Może to być prawda w oparciu o kod zapisany w standardowych bibliotekach, ale błędnie przyjmuje założenie, że zadaniem kompilatora optymalizacyjnego jest wygenerowanie napisanego kodu. Zadaniem kompilatora optymalizującego jest w rzeczywistości wygenerowanie kodu, który napisalibyście, gdybyście byli ekspertami w zakresie optymalizacji specyficznych dla platformy i nie dbali o łatwość konserwacji, tylko wydajność.

Rzeczywista różnica między tymi dwiema stwierdzeniami polega na tym, że silniejsze emplace_backwywołują dowolny konstruktor, podczas gdy bardziej ostrożne push_backbędą wywoływać tylko konstruktory, które są niejawne. Domniemane konstruktory powinny być bezpieczne. Jeśli możesz w sposób niejawny skonstruować Uz a T, mówisz, że Umoże przechowywać wszystkie informacje Tbez żadnych strat. Przechodzenie jest bezpieczne w prawie każdej sytuacji Ti nikt nie będzie miał nic przeciwko, jeśli zrobisz to Uzamiast. Dobrym przykładem niejawnego konstruktora jest konwersja z std::uint32_tna std::uint64_t. Zły przykład niejawna konwersja jest doubledo std::uint8_t.

Chcemy być ostrożni w naszym programowaniu. Nie chcemy korzystać z zaawansowanych funkcji, ponieważ im bardziej zaawansowana funkcja, tym łatwiej jest przypadkowo zrobić coś niepoprawnego lub nieoczekiwanego. Jeśli zamierzasz wywoływać jawne konstruktory, potrzebujesz mocy emplace_back. Jeśli chcesz wywoływać tylko niejawne konstruktory, trzymaj się bezpieczeństwa push_back.

Przykład

std::vector<std::unique_ptr<T>> v;
T a;
v.emplace_back(std::addressof(a)); // compiles
v.push_back(std::addressof(a)); // fails to compile

std::unique_ptr<T>ma jawny konstruktor z T *. Ponieważ emplace_backmożna wywoływać jawne konstruktory, przekazanie wskaźnika nie będącego właścicielem kompiluje się dobrze. Jednak gdy vwykracza poza zakres, destruktor spróbuje wywołać deleteten wskaźnik, który nie został przydzielony, newponieważ jest to tylko obiekt stosu. Prowadzi to do nieokreślonego zachowania.

To nie jest tylko wymyślony kod. To był prawdziwy błąd produkcyjny, z którym się spotkałem. Kod był std::vector<T *>, ale był właścicielem treści. W ramach migracji do C ++ 11, ja właściwie zmieniło T *się std::unique_ptr<T>w celu wskazania, że wektor własność swoją pamięć. Jednak te zmiany oparłem na swoim zrozumieniu w 2012 roku, podczas którego pomyślałem: „Situace_back robi wszystko, co może zrobić push_back i więcej, więc dlaczego miałbym kiedykolwiek używać push_back?”, Więc zmieniłem również push_backna emplace_back.

Gdybym zamiast tego zostawił kod jako bezpieczniejszy push_back, natychmiast złapałbym ten długotrwały błąd i byłby postrzegany jako sukces aktualizacji do C ++ 11. Zamiast tego zamaskowałem błąd i znalazłem go dopiero kilka miesięcy później.

push_backzawsze pozwala na użycie jednolitej inicjalizacji, co bardzo lubię. Na przykład:

struct aggregate {
    int foo;
    int bar;
};

std::vector<aggregate> v;
v.push_back({ 42, 121 });

Z drugiej strony v.emplace_back({ 42, 121 });nie będzie działać.

Kompatybilność wsteczna z kompilatorami wcześniejszymi niż C ++ 11.

Niektóre implementacje biblioteczne programu Situace_back nie zachowują się tak, jak określono w standardzie C ++, w tym wersja dostarczana z Visual Studio 2012, 2013 i 2015.

Aby uwzględnić znane błędy kompilatora, wolisz używać, std::vector::push_back()jeśli parametry odnoszą się do iteratorów lub innych obiektów, które będą niepoprawne po wywołaniu.

std::vector<int> v;
v.emplace_back(123);
v.emplace_back(v[0]); // Produces incorrect results in some compilers

W jednym kompilatorze v zawiera wartości 123 i 21 zamiast oczekiwanych 123 i 123. Wynika to z faktu, że drugie wywołanie emplace_backpowoduje zmianę rozmiaru, w którym punkt v[0]staje się nieważny.

Działająca implementacja powyższego kodu użyłaby push_back()zamiast emplace_back()następujących:

std::vector<int> v;
v.emplace_back(123);
v.push_back(v[0]);

Uwaga: użycie wektora liczb całkowitych służy do celów demonstracyjnych. Odkryłem ten problem ze znacznie bardziej złożoną klasą, która zawierała dynamicznie alokowane zmienne składowe i wezwanie do emplace_back()spowodowania ciężkiej awarii.