Почему массивы переменной длины не являются частью стандарта C ++?

Недавно в usenet началось обсуждение этого вопроса: Почему нет VLA в C ++ 0x.

Я согласен с теми людьми, которые, похоже, согласны с тем, что создание потенциально большого массива в стеке, в котором обычно мало свободного места, нехорошо. Аргумент в том, что если вы заранее знаете размер, вы можете использовать статический массив. А если заранее не знать размер, напишете небезопасный код.

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

Вы можете использовать std::vector, но это не совсем то же самое, поскольку он использует динамическую память, и заставить его использовать собственный стек-распределитель не совсем просто (выравнивание также является проблемой). Это также не решает ту же проблему, потому что вектор - это контейнер с изменяемым размером, тогда как VLA имеют фиксированный размер. Предложение C ++ Dynamic Array предназначено представить решение на основе библиотеки в качестве альтернативы VLA на основе языка. Однако, насколько мне известно, он не будет частью C ++ 0x.

(Предыстория: у меня есть некоторый опыт внедрения компиляторов C и C ++.)

Массивы переменной длины в C99 были ошибкой. Чтобы поддерживать VLA, C99 пришлось пойти на следующие уступки здравому смыслу:

• sizeof x больше не всегда является константой времени компиляции; компилятор иногда должен генерировать код для оценки sizeof-выражения во время выполнения.

• Разрешение двумерных VLA (int A[x][y]) потребовало нового синтаксиса для объявления функций, которые принимают 2D VLA в качестве параметров: void foo(int n, int A[][*]).

• Менее важно в мире C ++, но чрезвычайно важно для целевой аудитории C программистов встроенных систем, объявление VLA означает перебор произвольно большого фрагмента вашего стека. Это гарантированное переполнение стека и сбой. (Каждый раз, когда вы объявляете int A[n], вы неявно утверждаете, что у вас есть 2 ГБ свободного стека. В конце концов, если вы знаете, что «n здесь определенно меньше 1000», вы просто объявляете int A[1000]. Подставляя 32-битное целое число n ибо 1000 - это признание того, что вы понятия не имеете, каким должно быть поведение вашей программы.)

Хорошо, теперь перейдем к разговору о C ++. В C ++ существует такое же сильное различие между «системой типов» и «системой ценностей», что и в C89… но мы действительно начали полагаться на нее так, как этого не делал C. Например:

template<typename T> struct S { ... };
int A[n];
S<decltype(A)> s;  // equivalently, S<int[n]> s;

Если бы n не был константой времени компиляции (то есть, если бы A был переменно изменяемого типа), тогда что же, черт возьми, было бы типом S? Будет ли тип S также определяться только во время выполнения?

Как насчет этого:

template<typename T> bool myfunc(T& t1, T& t2) { ... };
int A1[n1], A2[n2];
myfunc(A1, A2);

Компилятор должен сгенерировать код для некоторого экземпляра myfunc. Как должен выглядеть этот код? Как мы можем статически сгенерировать этот код, если мы не знаем тип A1 во время компиляции?

Хуже того, что, если во время выполнения окажется, что n1 != n2, так что !std::is_same<decltype(A1), decltype(A2)>()? В этом случае вызов myfunc не должен даже компилироваться, потому что определение типа шаблона не сработает! Как мы могли бы эмулировать такое поведение во время выполнения?

По сути, C ++ движется в направлении принятия все большего и большего числа решений в время компиляции: генерация кода шаблона, constexpr оценка функции и так далее. Между тем, C99 был занят переносом традиционных решений времени компиляции (например, sizeof) в среду выполнения. Имея это в виду, действительно ли имеет смысл прилагать какие-либо усилия, пытаясь интегрировать VLA в стиле C99 в C ++?

Как уже отмечал каждый другой ответчик, C ++ предоставляет множество механизмов распределения кучи (std::unique_ptr<int[]> A = new int[n]; или std::vector<int> A(n); - очевидные), когда вы действительно хотите передать идею: «Я не знаю, сколько оперативной памяти мне может понадобиться». А C ++ предоставляет изящную модель обработки исключений для решения неизбежной ситуации, когда объем необходимой вам оперативной памяти превышает объем имеющейся у вас оперативной памяти. Но, надеюсь, этот ответ дает вам хорошее представление о том, почему VLA в стиле C99 не хорошо подходят для C ++ - и даже не подходят для C99. ;)

Для получения дополнительной информации по теме см. N3810 "Альтернативы для Array Extensions », статья Бьярна Страуструпа по VLA в октябре 2013 года. Точка зрения Бьярна сильно отличается от моей; N3810 больше фокусируется на поиске хорошего синтаксиса C ++ для вещей и на недопущении использования необработанных массивов в C ++, тогда как я больше сосредоточился на последствиях для метапрограммирования и системы типов. Я не знаю, считает ли он последствия метапрограммирования / типизации решенными, разрешимыми или просто неинтересными.

Хорошая запись в блоге, затрагивающая многие из этих вопросов, - «Законное использование массивов переменной длины» (Крис Веллонс, 27.10.2019).

Вы всегда можете использовать alloca () для выделения памяти в стеке во время выполнения, если хотите:

void foo (int n)
{
    int *values = (int *)alloca(sizeof(int) * n);
}

Выделение в стеке означает, что он будет автоматически освобожден при раскручивании стека.

Краткое примечание: как упоминалось на странице руководства Mac OS X для alloca (3), «Функция alloca () зависит от машины и компилятора; ее использование не рекомендуется». Просто чтобы вы знали.

В своей собственной работе я понял, что каждый раз, когда мне нужно что-то вроде автоматических массивов переменной длины или alloca (), мне было все равно, что память физически расположена в стеке процессора, просто она поступала из некоторый распределитель стека, который не вызывает медленных обращений к общей куче. Итак, у меня есть объект для каждого потока, который владеет некоторой памятью, из которой он может выталкивать / извлекать буферы переменного размера. На некоторых платформах я разрешаю этому расширяться через mmu. Другие платформы имеют фиксированный размер (обычно вместе со стеком ЦП фиксированного размера, потому что нет mmu). Одна платформа, с которой я работаю (портативная игровая консоль), в любом случае имеет драгоценный небольшой стек ЦП, потому что он находится в скудной быстрой памяти.

Я не говорю, что никогда не нужно помещать буферы переменного размера в стек процессора. Честно говоря, я был удивлен, когда обнаружил, что это не стандарт, так как определенно кажется, что концепция достаточно хорошо вписывается в язык. Однако для меня требования «переменный размер» и «физическое размещение в стеке процессора» никогда не совпадали. Речь шла о скорости, поэтому я сделал свой собственный «параллельный стек для буферов данных».

Кажется, это будет доступно в C ++ 14:

https://en.wikipedia.org/wiki/C++14#Runtime-sized_one_dimensional_arrays

Обновление: оно не вошло в C ++ 14.

Бывают ситуации, когда выделение памяти кучи очень дорого по сравнению с выполняемыми операциями. Примером является матричная математика. Если вы работаете с небольшими матрицами, скажем, от 5 до 10 элементов и выполняете много арифметических операций, накладные расходы malloc будут действительно значительными. В то же время создание константы времени компиляции для размера действительно кажется очень расточительным и негибким.

Я думаю, что C ++ настолько небезопасен сам по себе, что аргумент «старайтесь не добавлять больше небезопасных функций» не очень силен. С другой стороны, поскольку C ++, возможно, является наиболее эффективным языком программирования во время выполнения, функции, которые делают его еще более полезным, всегда полезны: люди, которые пишут программы, критичные к производительности, будут в значительной степени использовать C ++, и им нужна как можно большая производительность. Одна из таких возможностей - перемещение файлов из кучи в стек. Другое дело - уменьшение количества блоков кучи. Разрешение VLA в качестве членов объекта было бы одним из способов добиться этого. Я работаю над таким предложением. Правда, реализовать это немного сложно, но кажется вполне выполнимым.

Это рассматривалось для включения в C ++ / 1x, , но было отброшено (это это поправка к тому, что я сказал ранее).

В любом случае это было бы менее полезно в C ++, поскольку у нас уже есть std::vector для выполнения этой роли.

Используйте для этого std :: vector. Например:

std::vector<int> values;
values.resize(n);

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

Подобные массивы являются частью C99, но не являются частью стандартного C ++. как говорили другие, вектор всегда является гораздо лучшим решением, поэтому, вероятно, поэтому массивы переменного размера не входят в стандарт C ++ (или в предлагаемый стандарт C ++ 0x).

Кстати, на вопросы о том, "почему" стандарт C ++ такой, каков он есть, модерируемая группа новостей Usenet comp.std.c ++ - это то место, куда можно перейти.

C99 позволяет VLA. И это накладывает некоторые ограничения на то, как объявлять VLA. Подробнее см. 6.7.5.2 стандарта. C ++ запрещает VLA. Но g ++ это позволяет.

Если вы знаете значение во время компиляции, вы можете сделать следующее:

template <int X>
void foo(void)
{
   int values[X];

}

Изменить: вы можете создать вектор, который использует распределитель стека (alloca), поскольку распределитель является параметром шаблона.

У меня есть решение, которое действительно сработало для меня. Я не хотел выделять память из-за фрагментации подпрограммы, которую нужно было запускать много раз. Ответ чрезвычайно опасен, поэтому используйте его на свой страх и риск, но он использует сборку, чтобы зарезервировать место в стеке. В моем примере ниже используется массив символов (очевидно, для переменной другого размера потребуется больше памяти).

void varTest(int iSz)
{
    char *varArray;
    __asm {
        sub esp, iSz       // Create space on the stack for the variable array here
        mov varArray, esp  // save the end of it to our pointer
    }

    // Use the array called varArray here...  

    __asm {
        add esp, iSz       // Variable array is no longer accessible after this point
    } 
}

Опасностей здесь много, но я объясню несколько: 1. Изменение размера переменной на полпути приведет к уничтожению позиции стека 2. Выход за границы массива приведет к уничтожению других переменных и возможного кода 3. Это не работает в 64-битной системе. build ... для этого нужна другая сборка (но макрос может решить эту проблему). 4. Зависит от компилятора (могут возникнуть проблемы с переходом между компиляторами). Я не пробовал, поэтому действительно не знаю.