Блог

Я действительно не понимаю, почему у меня не может быть массива переменного размера в стеке, поэтому что-то вроде

 foo(int n) {
   int a[n];
}
  

Насколько я понимаю, стек (-сегмент) части сегмента данных и, следовательно, он не имеет «постоянного размера».

Массивы переменной длины (VLA) не разрешены в C в соответствии со стандартом C .
Многие компиляторы, включая gcc, поддерживают их как расширение компилятора, но важно отметить, что любой код, использующий такое расширение, непереносим.

C предоставляет std::vector для реализации функциональности, аналогичной VLA.

Было предложение ввести массивы переменной длины в C 11, но в конечном итоге оно было отклонено, поскольку для этого потребовались бы большие изменения в системе типов в C . Преимущество возможности создавать небольшие массивы в стеке без потери места или вызова конструкторов для неиспользуемых элементов было сочтено недостаточно значительным для больших изменений в системе типов C .

Я попытаюсь объяснить это на примере:

Допустим, у вас есть эта функция:

 int myFunc() {
   int n = 16;
   int arr[n];
   int k = 1;
}
  

Когда программа запускается, она устанавливает переменные таким образом в стек:

 - n @relative addr 0
- arr[16] @relative addr 4
- k @relative addr 64
TOTAL SIZE: 68 bytes
  

Допустим, я хочу изменить размер arr до 4 элементов. Я собираюсь сделать:

 delete arr;
arr = new int[4];
  

Теперь: если я оставлю стек таким образом, в стеке будут дыры неиспользуемого пространства. Итак, самое разумное, что можно сделать, это переместить все переменные из одного места в другое в стеке и пересчитать их позиции. Но нам чего-то не хватает: C не устанавливает позиции на лету, это делается только один раз, при компиляции программы. Почему? Это просто: потому что нет реальной необходимости иметь объекты переменного размера в стеке и потому, что их наличие замедлит работу всех программ при выделении / перераспределении пространства стека.

Это не единственная проблема, есть еще одна, еще большая: когда вы выделяете массив, вы решаете, сколько места он займет, и компилятор может предупредить вас, если вы превысите доступное пространство. Вместо этого, если вы позволяете программе выделять массивы переменного размера в вашем стеке, вы открываете брешив целях безопасности, поскольку вы делаете все программы, использующие этот метод, уязвимыми для переполнения стека.

Обратите внимание, что предложение было отклонено, и следующее больше не соответствует действительности. Однако он может быть восстановлен для будущей версии C .

VLA, описанный в N3639, был принят на собрании в Бристоле и станет частью C 14, а также частью библиотеки «dynarray». Итак, используя компилятор с поддержкой C 14, мы можем начать писать что-то вроде:

 void func(int n)
{
    int arr[n];
}
  

Или используйте dynarray:

 #include <dynarray>

void func(int n)
{
    std::dynarray<int> arr(n);
}
  

Простой ответ: потому что он не определен в стандарте C .

Не такой простой ответ: потому что в этом случае никто не предлагал что-то согласованное для C . В стандартах POV нет стека, он может быть реализован совершенно по-другому. В C99 есть VLA, но они кажутся настолько сложными в реализации, что gcc завершил реализацию только в версии 4.6. Я не думаю, что многие люди захотят предложить что-то для C и увидеть, как производители компиляторов борются с этим много лет.

Стеки довольно малы, и их размеры могут сильно различаться в зависимости от архитектуры. Проблема в том, что довольно легко «перераспределить» и вызвать ошибку seg или записать в память, принадлежащую кому-то другому. Между тем, решения проблемы (например vector ) существуют уже давно.

Черт возьми, я читал, что Страуструп сказал, что они ему не нужны, но я не знаю, в каком интервью это было.

Потому что в C статический массив нуждается в статическом постоянном размере, поэтому он не разрешен языком. Обратите внимание, что C99 поддерживает переменные массивы в стеке, а некоторые реализации поддерживают его в C , а также в качестве расширения.

Потому что так сказано в спецификации языка. Остальное не имеет значения (и объяснение с помощью сегментов ужасно неправильно по разным причинам).