Pourquoi `make_unique ` est-il interdit?

^{Supposons que l’espace de nom std}

Le projet N3690 du comité C ++ 14 définit std::make_unique ainsi:

[n3690: 20.9.1.4]: création unique_ptr [unique.ptr.create]

template unique_ptr make_unique(Args&&... args);

• Comment extraire le nom de fichier source sans chemin et sans suffixe lors de la compilation?
• Pourquoi n’y a-t-il pas de fonction std :: allocate_unique en C ++ 14?
• Recherche de nom non qualifiée: Pourquoi la déclaration locale empêche la déclaration d’utiliser la directive
• Peut-on omettre les doubles accolades pour std :: array en C ++ 14?
• Modèle de variable à la scope de la classe

1 Remarques: Cette fonction ne doit pas participer à la résolution de surcharge, sauf si T n’est pas un tableau.
2 renvoie: unique_ptr(new T(std::forward(args)...)).

template unique_ptr make_unique(size_t n);

3 Remarques: Cette fonction ne doit pas participer à la résolution de la surcharge sauf si T est un tableau de bornes inconnues.
4 renvoie: unique_ptr(new typename remove_extent::type[n]()).

template unspecified make_unique(Args&&...) = delete;

5 Remarques: Cette fonction ne participera pas à la résolution de la surcharge sauf si T est un tableau de liaisons connues.

Maintenant, cela me semble être à peu près aussi clair que de la boue et je pense que cela nécessite davantage d’exposition. Mais, mis à part ce commentaire éditorial, je crois avoir décodé le sens de chaque variante:

1. template unique_ptr make_unique(Args&&... args);

   Votre make_unique standard pour les types non-array. Vraisemblablement, la “remarque” indique qu’une certaine forme d’assertion statique ou astuce SFINAE consiste à empêcher l’instanciation du modèle lorsque T est un type de tableau.

   À un niveau élevé, voyez-le comme le pointeur intelligent équivalent à T* ptr = new T(args); .

2. template unique_ptr make_unique(size_t n);

   Une variante pour les types de tableau. Crée un tableau alloué de manière dynamic de n × Ts et le retourne dans un unique_ptr .

   À un niveau élevé, voyez-le comme le pointeur intelligent équivalent à T* ptr = new T[n]; .

3. template unspecified make_unique(Args&&...)

   Non autorisé. ” non spécifié ” serait probablement unique_ptr .

   Serait autrement le pointeur intelligent équivalent à quelque chose comme T[N]* ptr = new (keep_the_dimension_please) (the_dimension_is_constexpr) T[N]; invalide T[N]* ptr = new (keep_the_dimension_please) (the_dimension_is_constexpr) T[N]; .

Tout d’abord, ai-je raison? Et, si oui, que se passe-t-il avec la troisième fonction?

• S’il est possible d’empêcher les programmeurs d’essayer d’allouer de manière dynamic un tableau tout en fournissant des arguments de constructeur pour chaque élément (de même que new int[5](args) est impossible), cela est déjà couvert par le fait que la première fonction ne peut pas être instanciée pour les types de tableaux, n’est-ce pas?

• S’il est là pour empêcher l’ajout au langage d’une construction telle que T[N]* ptr = new T[N] (où N est un certain constexpr ), alors, pourquoi? Ne pourrait-il pas exister un unique_ptr qui enveloppe un bloc alloué de manière dynamic de N × T s? Serait-ce une si mauvaise chose, dans la mesure où le comité s’est make_unique d’empêcher sa création à l’aide de make_unique ?

Pourquoi make_unique interdit?

• Arity d’un lambda générique
• Invalidation de la référence après application de reverse_iterator sur un iterator personnalisé
• c ++ 11 programmation variadique, comment définir une tour de vecteurs
• trouver le type de voiture
• Pourquoi l’opérateur “” est-il caché dans un espace de noms?

 template< typename T, typename... Args > typename enable_if< !is_array< T >::value, unique_ptr< T > >::type make_unique( Args&&... args ) { return unique_ptr< T >( new T( forward< Args >( args )... ) ); } template< typename T > typename enable_if< is_array< T >::value && extent< T >::value == 0, unique_ptr< T > >::type make_unique( const size_t n ) { using U = typename remove_extent< T >::type; return unique_ptr< T >( new U[ n ]() ); }