std :: vector (ab) utilise le stockage automatique

Considérez l'extrait de code suivant:

#include <array>
int main() {
  using huge_type = std::array<char, 20*1024*1024>;
  huge_type t;
}

Évidemment, cela planterait sur la plupart des plates-formes, car la taille de pile par défaut est généralement inférieure à 20 Mo.

Considérez maintenant le code suivant:

#include <array>
#include <vector>

int main() {
  using huge_type = std::array<char, 20*1024*1024>;
  std::vector<huge_type> v(1);
}

Étonnamment, il se bloque également! Le traceback (avec l'une des versions récentes de libstdc ++) mène au include/bits/stl_uninitialized.hfichier, où nous pouvons voir les lignes suivantes:

typedef typename iterator_traits<_ForwardIterator>::value_type _ValueType;
std::fill(__first, __last, _ValueType());

Le vectorconstructeur de redimensionnement doit initialiser par défaut les éléments, et c'est ainsi qu'il est implémenté. De toute évidence, _ValueType()temporaire bloque la pile.

La question est de savoir s'il s'agit d'une implémentation conforme. Si oui, cela signifie en fait que l'utilisation d'un vecteur de types énormes est assez limitée, n'est-ce pas?

Il n'y a pas de limite sur la quantité de stockage automatique utilisée par l'API std.

Ils pourraient tous nécessiter 12 téraoctets d'espace de pile.

Cependant, cette API nécessite uniquement Cpp17DefaultInsertableet votre implémentation crée une instance supplémentaire par rapport à ce qui est requis par le constructeur. Sauf si elle est bloquée derrière la détection de l'objet est trivialement modifiable et copiable, cette implémentation semble illégale.

huge_type t;

Évidemment, cela planterait sur la plupart des plates-formes ...

Je conteste l'hypothèse de "la plupart". Étant donné que la mémoire de l'objet énorme n'est jamais utilisée, le compilateur peut l'ignorer complètement et ne jamais allouer la mémoire, auquel cas il n'y aurait pas de plantage.

La question est de savoir s'il s'agit d'une implémentation conforme.

La norme C ++ ne limite pas l'utilisation de la pile, ni ne reconnaît même l'existence d'une pile. Donc, oui, il est conforme à la norme. Mais on pourrait considérer qu'il s'agit d'un problème de qualité de mise en œuvre.

cela signifie en fait que l'utilisation d'un vecteur de types énormes est assez limitée, n'est-ce pas?

Cela semble être le cas avec libstdc ++. Le crash n'a pas été reproduit avec libc ++ (en utilisant clang), il semble donc que ce ne soit pas une limitation dans le langage, mais plutôt uniquement dans cette implémentation particulière.

Je ne suis ni juriste ni expert en standard C ++, mais cppreference.com dit:

explicit vector( size_type count, const Allocator& alloc = Allocator() );

Construit le conteneur avec le nombre d'instances de T. insérées par défaut. Aucune copie n'est effectuée.

Peut-être que je comprends mal "inséré par défaut", mais je m'attendrais à:

std::vector<huge_type> v(1);

être équivalent à

std::vector<huge_type> v;
v.emplace_back();

Cette dernière version ne doit pas créer de copie de pile mais construire un énorme_type directement dans la mémoire dynamique du vecteur.

Je ne peux pas dire avec autorité que ce que vous voyez n'est pas conforme, mais ce n'est certainement pas ce que j'attendrais d'une implémentation de qualité.