Po co używać std :: make_unique w C ++ 17?

O ile rozumiem, wprowadzono C ++ 14 std::make_unique, ponieważ w wyniku nieokreślenia kolejności oceny parametrów było to niebezpieczne:

f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A

(Wyjaśnienie: jeśli ocena najpierw przydzieli pamięć dla surowego wskaźnika, a następnie wywoła g()i wyjątek zostanie zgłoszony przed std::unique_ptrkonstrukcją, wtedy nastąpi wyciek pamięci).

Dzwonienie std::make_uniquebyło sposobem na ograniczenie kolejności połączeń, dzięki czemu wszystko było bezpieczne:

f(std::make_unique<MyClass>(param), g());             // Syntax B

Od tego czasu C ++ 17 wyjaśnił kolejność oceny, czyniąc również składnię A bezpieczną, więc oto moje pytanie: czy nadal istnieje powód, aby używać konstruktora std::make_uniqueover std::unique_ptrw C ++ 17? Czy możesz podać kilka przykładów?

Na razie jedyny powód, jaki mogę sobie wyobrazić, to to, że pozwala na wpisanie MyClasstylko raz (zakładając, że nie musisz polegać na polimorfizmie std::unique_ptr<Base>(new Derived(param))). Jednak wydaje się to dość słabym powodem, zwłaszcza gdy std::make_uniquenie pozwala na określenie deleter, podczas gdy std::unique_ptrkonstruktor to robi.

Żeby było jasne, nie opowiadam się za usunięciem std::make_uniquez biblioteki standardowej (zachowanie tego ma sens przynajmniej ze względu na wsteczną kompatybilność), ale raczej zastanawiam się, czy nadal istnieją sytuacje, w których zdecydowanie preferowane jeststd::unique_ptr

Masz rację, że główny powód został usunięty. Nadal istnieją nowe wytyczne dotyczące nieużywania nowych i mniej powodów związanych z pisaniem (nie trzeba powtarzać czcionki ani używać słowa new). Co prawda nie są to mocne argumenty, ale bardzo lubię nie widzieć neww moim kodzie.

Nie zapomnij też o konsystencji. Koniecznie powinieneś używać, make_sharedwięc używanie make_uniquejest naturalne i pasuje do wzoru. Zmiana std::make_unique<MyClass>(param)na std::make_shared<MyClass>(param)(lub odwrotnie) jest wtedy trywialna, gdzie składnia A wymaga znacznie więcej przepisania.

make_uniqueodróżnia Tod T[]i T[N], unique_ptr(new ...)nie.

Możesz łatwo uzyskać niezdefiniowane zachowanie, przekazując wskaźnik, który został new[]ed do a unique_ptr<T>, lub przekazując wskaźnik, który został newed do a unique_ptr<T[]>.

Powodem jest krótszy kod bez duplikatów. Porównać

f(std::unique_ptr<MyClass>(new MyClass(param)), g());
f(std::make_unique<MyClass>(param), g());

Można zaoszczędzić MyClass, newi szelki. To kosztuje tylko jeden znak więcej w marki w porównaniu z PTR .

Każde użycie newmusi być bardzo dokładnie sprawdzone pod kątem poprawności przez cały okres użytkowania; czy zostanie usunięty? Tylko raz?

Każde użycie make_uniquenie dla tych dodatkowych cech; tak długo, jak obiekt będący właścicielem ma „prawidłowy” czas życia, rekurencyjnie powoduje, że unikalny wskaźnik ma „poprawny”.

Otóż, prawdą jest, że unique_ptr<Foo>(new Foo())jest identyczny pod każdym względem od ¹ do make_unique<Foo>(); wymaga tylko prostszego "grep twojego kodu źródłowego do wszystkich zastosowań w newcelu ich audytu".

¹ właściwie kłamstwo w ogólnym przypadku. Idealne przekazywanie nie jest idealne, {}domyślny init, tablice są wyjątkami.

Od tego czasu C ++ 17 wyjaśnił kolejność oceny, czyniąc również składnię A bezpieczną

To naprawdę nie wystarczy. Poleganie na niedawno wprowadzonej klauzuli technicznej jako gwarancji bezpieczeństwa nie jest bardzo solidną praktyką:

• Ktoś mógłby skompilować ten kod w C ++ 14.
• Zachęcałbyś do używania surowego w newinnym miejscu, np. Kopiując i wklejając swój przykład.
• Jak sugeruje SM, ponieważ występuje duplikacja kodu, jeden typ może zostać zmieniony bez zmiany drugiego.
• Jakiś rodzaj automatycznej refaktoryzacji IDE może przenieść to newgdzie indziej (ok, prawda, nie ma na to dużej szansy).

Ogólnie rzecz biorąc, dobrym pomysłem jest, aby kod był odpowiedni / niezawodny / wyraźnie poprawny bez uciekania się do warstw językowych, wyszukiwania pomniejszych lub niejasnych klauzul technicznych w standardzie.

(jest to zasadniczo ten sam argument, który przedstawiłem tutaj na temat kolejności niszczenia krotek).

Rozważ void function (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...}

Załóżmy, że nowa A () się powiedzie, ale nowa B () zgłasza wyjątek: łapiesz ją, aby wznowić normalne wykonywanie programu. Niestety standard C ++ nie wymaga zniszczenia obiektu A i zwolnienia jego pamięci: pamięć po cichu przecieka i nie ma możliwości jej wyczyszczenia. Pakując A i B w std :: make_uniques, masz pewność, że wyciek nie wystąpi:

void function (std :: make_unique (), std :: make_unique ()) {...} Chodzi o to, że std :: make_unique i std :: make_unique są teraz obiektami tymczasowymi, a czyszczenie obiektów tymczasowych jest poprawnie określone w standard C ++: ich destruktory zostaną wyzwolone, a pamięć zwolniona. Więc jeśli możesz, zawsze wolisz przydzielać obiekty za pomocą std :: make_unique i std :: make_shared.