¿Habilitar VLA (matrices de longitud variable) en MS Visual C ++?

¿Cómo puedo habilitar el uso de VLA, matrices de longitud variable como se define en C99, en MS Visual C ++ o eso no es posible en absoluto?

Sí, sé que el estándar de C ++ se basa en C89 y que los VLA no están disponibles en C89 y por lo tanto no están disponibles en C ++, pero se supone que MSVC ++ también es un comstackdor de C, un comportamiento que se puede activar utilizando el / Parámetro comstackdor TC ( Compile as C Code (/TC) ). Pero hacerlo no parece habilitar los VLA y el proceso de comstackción falla con los mismos errores al Compile as C++ Code (/TP) ( Compile as C++ Code (/TP) ). Quizás el comstackdor MSVC ++ C solo cumple C89 o me falta algo (algún constructo especial o pragma / define)?

Muestra de código:

 #include  int main(int argc, char **argv) { char pc[argc+5]; /* do something useful with pc */ return EXIT_SUCCESS; } 

Comstackr errores:

error C2057: expresión constante esperada

error C2466: no se puede asignar una matriz de tamaño constante 0

error C2133: ‘pc’: tamaño desconocido

MSVC no es un comstackdor C99 y no admite matrices de longitud variable.

En https://docs.microsoft.com/en-us/cpp/c-language/ansi-conformance, MSVC está documentado como conforme a C90.

Los VLA son mucho más fáciles de escribir, pero puede obtener un comportamiento similar utilizando alloca() cuando la asignación de memoria dinámica de std::vector es prohibitiva.

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

Usar alloca() en tu ejemplo daría:

 #include  #include  int main(int argc, char **argv) { char* pc = (char*) alloca(sizeof(char) * (argc+5)); /* do something useful with pc */ return EXIT_SUCCESS; } 

Me encontré con el mismo problema, esto no es posible en MS Visual C ++ 2015, en su lugar puede usar el vector para hacer casi lo mismo, la única diferencia es la sobrecarga negligenciable de la rutina de administración de recursos del montón (nueva / eliminar).

Aunque los VLA son convenientes, asignar una cantidad de memoria no determinista de la stack en riesgo de desbordamiento de la stack generalmente no es una buena idea.