std :: vector (ab) używa automatycznego przechowywania

Rozważ następujący fragment kodu:

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

Oczywiście ulegnie awarii na większości platform, ponieważ domyślny rozmiar stosu jest zwykle mniejszy niż 20 MB.

Teraz rozważ następujący kod:

#include <array>
#include <vector>

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

Co zaskakujące, również się zawiesza! Tracback (z jedną z najnowszych wersji libstdc ++) prowadzi do include/bits/stl_uninitialized.hpliku, w którym możemy zobaczyć następujące linie:

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

Konstruktor zmiany rozmiaru vectormusi domyślnie zainicjować elementy i w ten sposób jest implementowany. Oczywiście _ValueType()tymczasowe awarie stosu.

Pytanie brzmi, czy jest to zgodna implementacja. Jeśli tak, to w rzeczywistości oznacza to, że użycie wektora ogromnych typów jest dość ograniczone, prawda?

Nie ma ograniczenia, ile automatycznej pamięci używa każdy interfejs std API.

Wszystkie mogą wymagać 12 terabajtów miejsca na stosie.

Jednak ten interfejs API wymaga tylko Cpp17DefaultInsertable, a twoja implementacja tworzy dodatkową instancję w stosunku do wymagań konstruktora. O ile implementacja nie jest ukryta za wykrywaniem obiektu, który można w trywialny sposób kopiować i kopiować, implementacja wygląda nielegalnie.

huge_type t;

Oczywiście miałoby to awarię na większości platform ...

Kwestionuję założenie „większości”. Ponieważ pamięć dużego obiektu nigdy nie jest używana, kompilator może go całkowicie zignorować i nigdy nie przydzielać pamięci, w którym to przypadku nie nastąpiłby awaria.

Pytanie brzmi, czy jest to zgodna implementacja.

Standard C ++ nie ogranicza użycia stosu, a nawet potwierdza istnienie stosu. Tak, to jest zgodne ze standardem. Można jednak uznać to za kwestię jakości wdrożenia.

w rzeczywistości oznacza to, że użycie wektora wielkich typów jest dość ograniczone, prawda?

Tak wydaje się być w przypadku libstdc ++. Katastrofa nie została odtworzona w libc ++ (przy użyciu clang), więc wydaje się, że nie jest to ograniczenie w języku, ale tylko w tej konkretnej implementacji.

Nie jestem prawnikiem językowym ani ekspertem od standardu C ++, ale cppreference.com mówi:

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

Konstruuje kontener z licznikami wstawionymi domyślnie instancjami T. Nie wykonuje się kopii.

Być może źle rozumiem „domyślnie wstawiony”, ale oczekiwałbym:

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

być równoważnym z

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

Ta ostatnia wersja nie powinna tworzyć kopii stosu, ale konstruować ogromny typ bezpośrednio w pamięci dynamicznej wektora.

Nie mogę autorytatywnie powiedzieć, że to, co widzisz, jest niezgodne, ale z pewnością nie jest to, czego oczekiwałbym od wysokiej jakości wdrożenia.