Включение VLA (массивов переменной длины) в MS Visual C ++?

Question

Как я могу разрешить использование VLA, массивов переменной длины, как определено в C99, в MS Visual C ++ или это вообще невозможно?

Да, я знаю, что стандарт C ++ основан на C89 и что VLA недоступны в стандарте C89 и, следовательно, недоступны в C ++, но MSVC ++ должен также быть компилятором C, поведение, которое можно переключать при использовании параметра компилятора / TC (Compile as C Code (/TC)). Но, похоже, это не позволяет включить VLA, и процесс компиляции завершается с теми же ошибками при сборке, что и C ++ (Compile as C++ Code (/TP)). Может быть, компилятор MSVC ++ C совместим только с C89 или мне чего-то не хватает (какая-то специальная конструкция или прагма / определение)?

Пример кода:

#include <stdlib.h>

int main(int argc, char **argv)
{
  char pc[argc+5];

  /* do something useful with pc */

  return EXIT_SUCCESS;
}

Ошибки компиляции:

ошибка C2057: ожидаемое постоянное выражение

ошибка C2466: невозможно выделить массив постоянного размера 0

ошибка C2133: «ПК»: неизвестный размер

Answer 1

MSVC не является компилятором C99 и не поддерживает массивы переменной длины.

В https://docs.microsoft.com/en-us/cpp/c-language/ansi-conformance MSVC зарегистрирован как соответствующий C90.

Answer 2

VLA гораздо удобнее в написании, но вы можете получить аналогичное поведение, используя alloca(), когда динамическое выделение памяти std::vector непомерно велико.

http://msdn.microsoft.com/en-us/library/x9sx5da1.aspx

Использование alloca() в вашем примере даст:

#include <stdlib.h>
#include <alloca.h>

int main(int argc, char **argv)
{
  char* pc = (char*) alloca(sizeof(char) * (argc+5));

  /* do something useful with pc */

  return EXIT_SUCCESS;
}

Answer 3

Я столкнулся с той же проблемой, это невозможно в MS Visual C ++ 2015, вместо этого вы можете использовать vector, чтобы сделать почти то же самое, единственное отличие - незначительные издержки процедуры управления ресурсами кучи (new / delete).

Хотя VLA и удобны, но выделять недетерминированный объем памяти из стека с риском переполнения стека, как правило, не очень хорошая идея.