std::dynarray vs std::vector
C++14 présente std::dynarray:
Std:: dynarray est un conteneur de séquence qui encapsule des tableaux avec un taille qui est fixée à la construction et ne change pas tout au long de la la durée de vie de l'objet.
std::dynarray doit être alloué au moment de l'exécution comme std::vector.
Quels sont Donc les avantages et l'utilisation de std::dynarray, alors que nous pouvons utiliser std::vector, qui est plus dynamique (et aussi re-dimensionnées)?
2 réponses
Alors, quels sont les avantages et l'utilisation de
std::dynarray, Quand on peut utiliserstd::vectorqui est plus dynamique (redimensionnable)?
dynarray est plus petit et plus simple que vector, car il n'a pas besoin de gérer des valeurs de taille et de capacité séparées, et il n'a pas besoin de stocker un allocateur.
Cependant, le principal avantage de performance est destiné à provenir du fait que les implémentations sont encouragées à allouer dynarray sur la pile lorsque cela est possible, en évitant toute allocation de tas. par exemple
std::dynarray<int> d(5); // can use stack memory for elements
auto p = new std::dynarray<int>(6); // must use heap memory for elements
Cette optimisation nécessite la coopération du compilateur, elle ne peut pas être implémentée en tant que type de bibliothèque pure, et la magie du compilateur nécessaire n'a pas été implémentée et personne n'est sûr de la facilité à faire. En raison du manque d'expérience dans la mise en œuvre, lors de la réunion du Comité C++ à Chicago la semaine dernière, il a été décidé de tirer std::dynarray de C++14 et de publier un document distinct array extensions TS (technical specification) définissant std::experimental::dynarray et arrays of runtime bound (ARBs, similaire à C99 VLAs.) Cela signifie que std::dynarray ne sera presque certainement pas en C++14.
Comme vous l'avez dit vous-même, std::dynarray est un de taille fixe tableau dynamique. Il n'est pas redimensionnable. C'est grosso modo une amélioration par rapport à new T[N] et sur std::unique_ptr<T[]>(new T[N]).
Ne pas avoir besoin de redimensionner ou de gérer la capacité signifie que vous pouvez implémenter la structure de données avec moins de complexité et moins d'espace.
De plus, std::dynarray est un animal étrange qui permet à l'implémentation de l'implémenter de différentes manières non spécifiques, par exemple il est possible de mettre le tableau sur la pile. L'appel d'un affectation de la fonction est "facultatif". Vous pouvez spécifier un allocateur pour construire les éléments du tableau, mais cela ne fait pas partie du type.
Vous pourriez aussi vous demander pourquoi nous avons besoin std::dynarray et tableaux de longueur variable. Les VLAs en C++14 sont beaucoup plus restrictifs; ils ne peuvent être que des variables locales et automatiques et n'offrent aucun moyen de spécifier une politique d'allocation, et bien sûr ils n'ont pas d'interface de conteneur standard.
Quelques exemples de 23.3.4.2 d'un " projet actuel" (prenez cela, Google cache):
explicit dynarray(size_type c);effets: alloue le stockage pour les éléments
c. peut ou non invoquer le globaloperator new.
template <class Alloc> dynarray(size_type c, const Alloc& alloc);effets: équivalent aux constructeurs précédents sauf que chaque élément est construit avec uses - allocator construction .
Si vous pouvez utiliser un allocateur donné pour construire les éléments du tableau est un global trait de caractère:
Modèle struct uses_allocator, Alloc> : true_type { };
nécessite:
Allocdoit être un allocateur (17.6.3.5). [ Note: La spécialisation de ce trait informe les autres composants de la bibliothèque quedynarraypeut être construit avec un allocator, même s'il n'a pas de allocator_type imbriqué.]
Edit: la réponse de Jonathan Wakely devrait être beaucoup plus autoritaire et perspicace.