make_unique i idealne przekazywanie

Dlaczego std::make_uniquew standardowej bibliotece C ++ 11 nie ma szablonu funkcji? znajduję

std::unique_ptr<SomeUserDefinedType> p(new SomeUserDefinedType(1, 2, 3));

trochę gadatliwy. Czy poniższe rzeczy nie byłyby o wiele ładniejsze?

auto p = std::make_unique<SomeUserDefinedType>(1, 2, 3);

To newładnie ukrywa i wspomina o typie tylko raz.

Tak czy inaczej, oto moja próba wdrożenia make_unique:

template<typename T, typename... Args>
std::unique_ptr<T> make_unique(Args&&... args)
{
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

Sporo czasu zajęło mi std::forwardskompilowanie tego pliku , ale nie jestem pewien, czy jest poprawny. Czy to jest Co dokładnie std::forward<Args>(args)...znaczy? Co robi z tego kompilator?

Herb Sutter, przewodniczący komitetu normalizacyjnego C ++, pisze na swoim blogu :

To, że C ++ 11 nie obejmuje, make_uniquejest częściowo niedopatrzeniem i prawie na pewno zostanie dodane w przyszłości.

Podaje także implementację identyczną z tą podaną przez PO.

Edycja: std::make_unique teraz jest częścią C ++ 14 .

Fajnie, ale Stephan T. Lavavej (lepiej znany jako STL) ma lepsze rozwiązanie make_unique, które działa poprawnie dla wersji tablicowej.

#include <memory>
#include <type_traits>
#include <utility>

template <typename T, typename... Args>
std::unique_ptr<T> make_unique_helper(std::false_type, Args&&... args) {
  return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

template <typename T, typename... Args>
std::unique_ptr<T> make_unique_helper(std::true_type, Args&&... args) {
   static_assert(std::extent<T>::value == 0,
       "make_unique<T[N]>() is forbidden, please use make_unique<T[]>().");

   typedef typename std::remove_extent<T>::type U;
   return std::unique_ptr<T>(new U[sizeof...(Args)]{std::forward<Args>(args)...});
}

template <typename T, typename... Args>
std::unique_ptr<T> make_unique(Args&&... args) {
   return make_unique_helper<T>(std::is_array<T>(), std::forward<Args>(args)...);
}

Można to zobaczyć na jego filmie Core C ++ 6 .

Zaktualizowana wersja make_unique STL jest teraz dostępna jako N3656 . Ta wersja została przyjęta do wersji roboczej C ++ 14.

std::make_sharednie jest tylko skrótem std::shared_ptr<Type> ptr(new Type(...));. Robi coś, bez czego nie można się obejść.

Aby wykonać swoje zadanie, std::shared_ptrmusi przydzielić blok śledzenia oprócz przechowywania pamięci dla rzeczywistego wskaźnika. Ponieważ jednak std::make_sharedalokuje rzeczywisty obiekt, możliwe jest, że std::make_sharedalokuje zarówno obiekt, jak i blok śledzenia w tym samym bloku pamięci.

Tak więc podczas gdy std::shared_ptr<Type> ptr = new Type(...);byłyby dwa przydziały pamięci (jeden dla new, jeden w std::shared_ptrbloku śledzenia), std::make_shared<Type>(...)przydzieliłby jeden blok pamięci.

Jest to ważne dla wielu potencjalnych użytkowników std::shared_ptr. Jedyne, co std::make_uniquemożna zrobić, to nieco wygodniej. Nic więcej.

Chociaż nic nie stoi na przeszkodzie, aby napisać własnego pomocnika, uważam, że głównym powodem udostępnienia make_shared<T>w bibliotece jest to, że faktycznie tworzy on inny wewnętrzny typ wskaźnika wspólnego niż shared_ptr<T>(new T), który jest inaczej przydzielany, i nie ma sposobu, aby to osiągnąć bez dedykowanego pomocnik.

make_uniqueZ drugiej strony twoje opakowanie to zwykły cukier syntaktyczny wokół newwyrażenia, więc chociaż może wyglądać przyjemnie dla oka, nie przynosi niczego newna stół. Korekta: w rzeczywistości nie jest to prawdą: wywołanie funkcji w celu zawinięcia newwyrażenia zapewnia bezpieczeństwo wyjątków, na przykład w przypadku wywołania funkcji void f(std::unique_ptr<A> &&, std::unique_ptr<B> &&). Posiadanie dwóch nieprzetworzonych względem siebie surowych newznaków oznacza, że ​​jeśli jedno nowe wyrażenie zawiedzie z wyjątkiem, drugie może przeciekać zasoby. Jeśli chodzi o to, dlaczego nie ma tego make_uniquew normie: zostało po prostu zapomniane. (Zdarza się to czasami. W std::cbeginstandardzie nie ma również globalnego, chociaż powinien istnieć.)

Zauważ też, że unique_ptrbierze drugi parametr szablonu, na który powinieneś jakoś zezwolić; różni się to od tego shared_ptr, który używa kasowania typu do przechowywania niestandardowych programów usuwających bez włączania ich do typu.

W C ++ 11 ...jest używany (w kodzie szablonu) również do „rozszerzenia pakietu”.

Wymagane jest, abyś używał go jako sufiksu wyrażenia zawierającego nierozwiniętą paczkę parametrów, a po prostu zastosuje to wyrażenie do każdego z elementów paczki.

Na przykład, opierając się na twoim przykładzie:

std::forward<Args>(args)... -> std::forward<int>(1), std::forward<int>(2),
                                                     std::forward<int>(3)

std::forward<Args...>(args...) -> std::forward<int, int, int>(1,2,3)

To ostatnie jest niepoprawne.

Ponadto pakiet argumentów nie może być przekazany do funkcji nierozwiniętej. Nie jestem pewien co do zestawu parametrów szablonu.

Zainspirowany wdrożeniem Stephana T. Lavaveja, pomyślałem, że fajnie byłoby mieć make_unique, który obsługiwałby zakresy tablic, jest na githubie i chciałbym otrzymywać komentarze na jego temat. Pozwala to zrobić:

// create unique_ptr to an array of 100 integers
auto a = make_unique<int[100]>();

// create a unique_ptr to an array of 100 integers and
// set the first three elements to 1,2,3
auto b = make_unique<int[100]>(1,2,3);