размер кадра стека всегда фиксирован?

Во время выполнения программы на C ++ всегда ли кадр стека конкретной функции имеет постоянный размер, или компилятору разрешено выполнять динамическое управление стеками в некоторых случаях, что-то похожее на то, что делает функция alloca ()? чтобы лучше описать это, я имею в виду смещение конкретной локальной переменной или объекта в стековом фрейме, которое может меняться при разных выполнениях функции

3

Решение

В распространенных реализациях локальные переменные помещаются в кадр стека. Некоторые функции могут иметь переменные, которые размещаются в регистрах, другие будут иметь переменные, размещенные в стеке.

Фреймы стека также могут быть расширены нестатическими переменными, объявленными в блоках операторов.

Не существует стандартного минимального размера для стекового фрейма. Максимальный размер стекового фрейма зависит от платформы и реализации. Обычной реализацией является расширение стека к куче, а кучи — к стеку.

1

Другие решения

По крайней мере, в большинстве типичных реализаций стековый фрейм для функции с переменными значениями варьируется в зависимости от того, сколько переменных передано. Например:

printf("%d", 1); // stack frame contains 1 pointer, one int
printf("%d %d", 1, 2); // stack frame contains one pointer, 2 ints.

Является ли реализация особенно похожа на alloca хотя зависит от реализации (тем более что alloca не является стандартным, так как или даже если это реализовано, может отличаться).

3

Компилятору разрешено делать все, что он пожелает, в конце концов он генерирует код и до тех пор, пока он делает то, что программа на C ++ говорит, что все в порядке. В общем случае, когда это возможно, компиляторы вычисляют общее необходимое пространство стека для функции и резервируют это заранее (уменьшая количество раз, в которое регистр стека записывается), даже если объекты создаются и уничтожаются по требованию.

3

Стандарт ничего не говорит об этом (он даже не требует наличия стека), и в C ++ 14, вероятно, понадобится что-то вроде alloca, поскольку он, скорее всего, получит «облегченную» версию C99 VLA.

1