std :: vector (ab) utilizza l'archiviazione automatica

Considera il seguente frammento:

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

Ovviamente si bloccherebbe sulla maggior parte delle piattaforme, perché la dimensione dello stack predefinita è generalmente inferiore a 20 MB.

Ora considera il seguente codice:

#include <array>
#include <vector>

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

Sorprendentemente si blocca anche! Il traceback (con una delle versioni libstdc ++ recenti) porta al include/bits/stl_uninitialized.hfile, dove possiamo vedere le seguenti righe:

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

Il vectorcostruttore di ridimensionamento deve inizializzare per default gli elementi, ed è così che viene implementato. Ovviamente, il _ValueType()crash temporaneo dello stack.

La domanda è se si tratta di un'implementazione conforme. Se sì, in realtà significa che l'uso di un vettore di tipi enormi è piuttosto limitato, non è vero?

Non vi è alcun limite alla quantità di memoria automatica utilizzata da qualsiasi API std.

Tutti potrebbero richiedere 12 terabyte di spazio stack.

Tuttavia, tale API richiede solo Cpp17DefaultInsertablee l'implementazione crea un'istanza aggiuntiva rispetto a quanto richiesto dal costruttore. A meno che non sia chiuso dietro il rilevamento dell'oggetto è banalmente gestibile e copiabile, l'implementazione sembra illegale.

huge_type t;

Ovviamente andrebbe in crash sulla maggior parte delle piattaforme ...

Contesto l'assunto di "maggior parte". Poiché la memoria dell'enorme oggetto non viene mai utilizzata, il compilatore può ignorarlo completamente e non allocare mai la memoria, nel qual caso non si verifica alcun arresto anomalo.

La domanda è se si tratta di un'implementazione conforme.

Lo standard C ++ non limita l'uso dello stack né riconosce l'esistenza di uno stack. Quindi sì, è conforme allo standard. Ma si potrebbe considerare che questo sia un problema di qualità dell'attuazione.

significa in realtà che l'uso di un vettore di tipi enormi è piuttosto limitato, no?

Questo sembra essere il caso di libstdc ++. L'incidente non è stato riprodotto con libc ++ (usando clang), quindi sembra che questo non sia un limite nel linguaggio, ma piuttosto solo in quella particolare implementazione.

Non sono un avvocato linguista né un esperto di standard C ++, ma cppreference.com dice:

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

Crea il contenitore con il numero di istanze di T. inserite per impostazione predefinita. Non vengono eseguite copie.

Forse sto fraintendendo "inserito per impostazione predefinita", ma mi aspetterei:

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

essere equivalente a

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

L'ultima versione non dovrebbe creare una copia dello stack ma costruire un tipo enorme direttamente nella memoria dinamica del vettore.

Non posso dire autorevolmente che ciò che vedi non è conforme, ma non è certamente quello che mi aspetterei da un'implementazione di qualità.