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

Considere o seguinte trecho:

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

Obviamente, ele travaria na maioria das plataformas, porque o tamanho da pilha padrão geralmente é inferior a 20 MB.

Agora considere o seguinte código:

#include <array>
#include <vector>

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

Surpreendentemente, ele também trava! O traceback (com uma das versões recentes do libstdc ++) leva ao include/bits/stl_uninitialized.harquivo, onde podemos ver as seguintes linhas:

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

O vectorconstrutor de redimensionamento deve inicializar os elementos por padrão, e é assim que ele é implementado. Obviamente, _ValueType()falhas temporárias na pilha.

A questão é se é uma implementação em conformidade. Se sim, na verdade significa que o uso de um vetor de grandes tipos é bastante limitado, não é?

Não há limite para a quantidade de armazenamento automático que qualquer API padrão usa.

Todos eles podem exigir 12 terabytes de espaço na pilha.

No entanto, essa API requer apenas Cpp17DefaultInsertablee sua implementação cria uma instância extra sobre o que é exigido pelo construtor. A menos que esteja atrasado para detectar que o objeto é trivialmente copiável e copiável, essa implementação parece ilegal.

huge_type t;

Obviamente, ele falharia na maioria das plataformas ...

Eu discuto a suposição de "a maioria". Como a memória do objeto enorme nunca é usada, o compilador pode ignorá-lo completamente e nunca alocar a memória; nesse caso, não haveria falha.

A questão é se é uma implementação em conformidade.

O padrão C ++ não limita o uso da pilha, nem reconhece a existência de uma pilha. Então, sim, está em conformidade com o padrão. Mas pode-se considerar que este é um problema de qualidade de implementação.

na verdade, significa que o uso de um vetor de tipos enormes é bastante limitado, não é?

Esse parece ser o caso do libstdc ++. A falha não foi reproduzida com libc ++ (usando clang), portanto, parece que isso não é uma limitação na linguagem, mas apenas nessa implementação específica.

Não sou advogado de idiomas nem especialista em C ++, mas o cppreference.com diz:

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

Constrói o contêiner com contagem de instâncias inseridas por padrão de T. Nenhuma cópia é feita.

Talvez eu esteja entendendo mal "inserção padrão", mas eu esperaria:

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

ser equivalente a

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

A última versão não deve criar uma cópia de pilha, mas construir um tipo enorme diretamente na memória dinâmica do vetor.

Não posso dizer com autoridade que o que você está vendo não é compatível, mas certamente não é o que eu esperaria de uma implementação de qualidade.