ошибки компилятора — Как статически размещенный массив переменного размера работает в C ++?
#include <iostream>
using namespace std;
int main(int argc, const char * argv[])
{
int size;
cin >> size;
int myArray[size]; //this shouldn't compile , right ?
return 0;
}
Я думал, что это не скомпилируется, но на самом деле (с помощью команды g ++).
Позже я выяснил, что GCC фактически допускает массивы переменного размера, даже если по стандарту C ++ не поддерживает массивы переменного размера, что странно! Потому что я слышал, как все говорят, что единственный способ создать массив переменного размера — это использовать динамическое распределение, например int* array = new int[size]; или лучше std::vector, Я думал, что GCC не допустит этот кусок кода!
Во всяком случае, мой теоретический вопрос в том, myArray массив выделяется в куча или же стек площадь ?
Решение
Это расширение на стороне компилятора. Как это работает? Ну работает только до некоторой степени.
Реализация в основном перемещает указатель стека на величину, которая зависит от размера массива, и вызывает память в середине по имени массива. Это работает только в некоторой степени, потому что в VLA размер не является неотъемлемой частью типа, что означает, что многие конструкции, которые могут использоваться в обычных массивах, не могут быть выполнены с этим типом, как, например, передача массива в шаблон по ссылке … sizeof обычно поставляется, но реализуется как конструкция времени выполнения.
Другие решения
myArray в вашем примере размещается в стеке. G ++ имеет расширение, которое позволяет этот трюк. Для этого не требуется куча, компилятор просто генерирует код для увеличения указателя стека на величину, вычисляемую во время выполнения.
VLA являются расширение, у многих реализаций есть собственные расширения языка C ++. Если вы хотите, чтобы g ++ жаловался, что вы не придерживаетесь стандарта, передайте -pedantic флаг. VLA находятся в стеке, что очень быстро, однако это также является причиной проблем, поскольку у вас ограниченное пространство стека. В С ++, однако, у нас есть такие конструкции, как std::vectorи т. д., так что в этом нет необходимости.
detector