std :: vector (ab) usa almacenamiento automático

Considere el siguiente fragmento:

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

Obviamente, se bloqueará en la mayoría de las plataformas, porque el tamaño predeterminado de la pila suele ser inferior a 20 MB.

Ahora considere el siguiente código:

#include <array>
#include <vector>

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

¡Sorprendentemente también se bloquea! El rastreo (con una de las versiones recientes de libstdc ++) conduce al include/bits/stl_uninitialized.harchivo, donde podemos ver las siguientes líneas:

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

El cambio de tamaño vector constructor de debe inicializar por defecto los elementos, y así es como se implementa. Obviamente, _ValueType()temporal bloquea la pila.

La pregunta es si se trata de una implementación conforme. En caso afirmativo, en realidad significa que el uso de un vector de tipos enormes es bastante limitado, ¿no es así?

No hay límite en cuanto al almacenamiento automático que utiliza cualquier API estándar.

Todos podrían requerir 12 terabytes de espacio de pila.

Sin embargo, esa API solo requiere Cpp17DefaultInsertable, y su implementación crea una instancia adicional sobre lo que requiere el constructor. A menos que esté cerrado detrás de detectar que el objeto es trivialmente copiable y copiable, esa implementación parece ilegal.

huge_type t;

Obviamente se estrellaría en la mayoría de las plataformas ...

Disputo la suposición de "la mayoría". Dado que la memoria del gran objeto nunca se usa, el compilador puede ignorarlo por completo y nunca asignar la memoria, en cuyo caso no habría bloqueo.

La pregunta es si se trata de una implementación conforme.

El estándar C ++ no limita el uso de la pila, ni siquiera reconoce la existencia de una pila. Entonces, sí, se ajusta al estándar. Pero se podría considerar que se trata de un problema de calidad de implementación.

en realidad significa que el uso de un vector de tipos enormes es bastante limitado, ¿no es así?

Ese parece ser el caso con libstdc ++. El bloqueo no se reprodujo con libc ++ (usando clang), por lo que parece que esto no es una limitación en el lenguaje, sino solo en esa implementación particular.

No soy un abogado de idiomas ni un experto en estándares de C ++, pero cppreference.com dice:

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

Construye el contenedor con el recuento de instancias de T. insertadas por defecto. No se realizan copias.

Quizás estoy malinterpretando "insertado por defecto", pero esperaría:

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

ser equivalente a

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

La última versión no debería crear una copia de la pila, sino construir un enorme_tipo directamente en la memoria dinámica del vector.

No puedo decir con autoridad que lo que está viendo no cumple, pero ciertamente no es lo que esperaría de una implementación de calidad.