make_unique et transfert parfait

Pourquoi n'y a-t-il pas de std::make_uniquemodèle de fonction dans la bibliothèque C ++ 11 standard? je trouve

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

un peu bavard. Les éléments suivants ne seraient-ils pas beaucoup plus agréables?

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

Cela cache newbien et ne mentionne le type qu'une seule fois.

Quoi qu'il en soit, voici ma tentative d'implémentation de 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)...));
}

Il m'a fallu un certain temps pour obtenir les std::forwardéléments à compiler, mais je ne sais pas si c'est correct. C'est ça? Que std::forward<Args>(args)...signifie exactement ? Qu'est-ce que le compilateur en fait?

Herb Sutter, président du comité de normalisation C ++, écrit sur son blog :

Ce que C ++ 11 n'inclut pas make_uniqueest en partie un oubli, et il sera presque certainement ajouté à l'avenir.

Il donne également une implémentation identique à celle donnée par le PO.

Edit: fait std::make_unique maintenant partie de C ++ 14 .

Bien, mais Stephan T. Lavavej (mieux connu sous le nom de STL) a une meilleure solution pour make_unique, qui fonctionne correctement pour la version tableau.

#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)...);
}

Cela peut être vu sur sa vidéo Core C ++ 6 .

Une version mise à jour de la version STL de make_unique est désormais disponible sous le numéro N3656 . Cette version a été adoptée dans le projet C ++ 14.

std::make_sharedn'est pas seulement un raccourci pour std::shared_ptr<Type> ptr(new Type(...));. Il fait quelque chose que vous ne pouvez pas faire sans lui.

Afin de faire son travail, std::shared_ptrdoit allouer un bloc de suivi en plus de conserver le stockage pour le pointeur réel. Cependant, comme il std::make_sharedalloue l'objet réel, il est possible qu'il std::make_sharedalloue à la fois l'objet et le bloc de suivi dans le même bloc de mémoire.

Donc, alors std::shared_ptr<Type> ptr = new Type(...);qu'il y aurait deux allocations de mémoire (une pour le new, une dans le std::shared_ptrbloc de suivi), std::make_shared<Type>(...)allouerait une bloc de mémoire.

C'est important pour de nombreux utilisateurs potentiels de std::shared_ptr. La seule chose à std::make_uniquefaire serait d'être un peu plus pratique. Rien de plus que ça.

Bien que rien ne vous empêche d'écrire votre propre assistant, je pense que la principale raison de fournir make_shared<T>dans la bibliothèque est qu'il crée en fait un type de pointeur partagé différent de celui shared_ptr<T>(new T)qui est différemment alloué, et il n'y a aucun moyen d'y parvenir sans le dédié assistant.

Votre make_uniqueemballage, d'autre part, n'est que du sucre syntaxique autour d'une newexpression, alors même s'il peut sembler agréable à l'œil, il n'apporte rien newà la table. Correction: ce n'est pas vrai en fait: avoir un appel de fonction pour encapsuler l' newexpression offre une sécurité d'exception, par exemple dans le cas où vous appelez une fonction void f(std::unique_ptr<A> &&, std::unique_ptr<B> &&). Avoir deux news bruts non séquencés l'un par rapport à l'autre signifie que si une nouvelle expression échoue avec une exception, l'autre peut entraîner une fuite de ressources. Quant à savoir pourquoi il n'y a pas make_uniquedans la norme: c'était juste oublié. (Cela se produit occasionnellement. Il n'y a pas non plus destd::cbegin dans la norme même s'il devrait y en avoir un.)

Notez également que unique_ptrprend un deuxième paramètre de modèle que vous devriez en quelque sorte autoriser; ceci est différent de shared_ptr, qui utilise l'effacement de type pour stocker des suppresseurs personnalisés sans les intégrer au type.

En C ++ 11 ... est également utilisé (dans le code modèle) pour "l'expansion du pack".

L'exigence est que vous l'utilisiez comme suffixe d'une expression contenant un pack de paramètres non développé, et il appliquera simplement l'expression à chacun des éléments du pack.

Par exemple, en s'appuyant sur votre exemple:

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)

Ce dernier étant incorrect je pense.

De plus, un pack d'arguments ne peut pas être passé à une fonction non développée. Je ne suis pas sûr d'un pack de paramètres de modèle.

Inspiré par l'implémentation de Stephan T. Lavavej, j'ai pensé qu'il serait bien d'avoir une make_unique qui supporte les extensions de tableau, c'est sur github et j'aimerais avoir des commentaires à ce sujet. Cela vous permet de faire ceci:

// 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);