[c++][arrays De Tamaño Variable]

[deadLock++]

 Siempre en mi vida pensé que el siguiente código era erróneo:

Código [Seleccionar] Expand


void foo (int i)
{
   int aiNums[i];

   // ...
}


Debido a que el valor encerrado entre corchetes debería ser una expresión constante, así fue siempre y así lo enuncia la página 89 del libro "El lenguaje de programación C++ " de Bjarne Stroustrup (tercera edición).

Sin embargo el código anterior es compilable por el DevC++ (que utiliza el gcc 3.2) y funciona a la perfección.

¿Qué es lo que pasó? ¿Hubo una modificación en la especificación del lenguaje que permite ahora dicha expresión?  :blink:

Muchas gracias.

[DraKKaR]

 En VisualC 6 da un error de compilación, como era de esperar:

Código [Seleccionar] Expand

expected constant expression

En cambio, en linux con el gcc 3.3.2 compila perfectamente! yo también me he quedao asombrado, porque siempre he creido que eso era incorrecto.

Aunque ahora que lo pienso, no se que problemas podría tener el implementar esa capacidad del lenguaje, lo veo perfectamente posible, ya que no es lo mismo eso que un array de tamaño variable. En realidad no varía, simplemente que según el parámetro reserva una cantidad de memoria u otra.

[CoLSoN2]

 supongo que con "tamaño variable" se refiere a usar una variable para indicar el tamaño, y por lo tanto en compilación no sabe cuanto es, porque aún no has llamado a la función.

[sés]

 Al ser local, se crea en la pila y, por lo tanto, en tiempo de ejecución. No veo creo que haya ningún problema ahí.

Me imagino que el problema sería si la variable fuera global. Prueba a definirla global, a ver si también te deja.

[Jikan]

 
  Si el código anterior compila (y funciona) correctamente, el compilador no es estándar. Hay compiladores que soportan una serie de opciones no contempladas en el estándar ISO de C++. No digo que sea bueno ni malo, pero no es estándar y por tanto el código no es portable.

  Un saludo,

                     Jikan

[Loover]

 Curioso.
Pues nada, utiliza un new para que sea portable.

[fiero]

 

Al ser local, se crea en la pila y, por lo tanto, en tiempo de ejecución. No veo creo que haya ningún problema ahí.

El problema que veo es si el tamaño del array es tan grande que no quepa en la pila asignada por defecto al inicio del programa. O puede ser que internamente el gcc 3.3.2 convierta esta expresión en una asignación dinámica transparente al programador:

Código [Seleccionar] Expand

void foo (int i)
{
  int aiNums[i];

  // ...
}

lo convierta en:

void foo (int i)
{
  int *aiNums;
  aiNums=new int[i];

  // ...
  delete aiNums;
}
Yo creo que convertirá el código en vez de una reserva variable en pila.

un saludo

[synchrnzr]

 

Yo creo que convertirá el código en vez de una reserva variable en pila.

Yo también lo veo más probable. Aunque la memoria de las variables locales se reserva dentro de la pila durante la ejecución, lo normal es conocer el tamaño en tiempo de compilación para generar el código que crea (LINK, ENTER...) y libera (UNLINK, LEAVE...) el enlace dinámico.

Se podría operar directamente sobre los registros de la pila para conseguir el mismo resultado, pero no tiene ninguna lógica. Eso complicaría mucho el código de llamada a la función. Imaginaos que, en vez de uno, se declaran muchos arrays de este tipo. Poder hacerse se puede, pero creo que en la práctica es más lógico que pase lo que dice fiero :)

sync

[ethernet]

 Yo creo que puede ser un cosas de const, me explico:
si llamas a la funcion asi: foo(3); el valor 3 es const y quizas el compilador optimice el codigo de manera que en compilacion pueda saber el valor de i y asignarlo. Es algo raro pero prueba a hacer int i  = rand(); foo(i); a ver si rula


EDIT:

http://www.mail-archive.com/gcc-bugs@gcc.g...g/msg55086.html

saludos

[_Grey]

 Ese codigo es ERRONEO, por lo menos en el C de toda la vida (ANSI), otra cosa, es que el mundo esta lleno de gente que hace las cosas a su manera, es decir eso es una caracteristica de algunos en concreto.... como decirlo..... creo recordar que en algun compilata de Borland, ademas de usar ">>" usan ">>>" para rellenar con ceros o algo asi...... pero cuidado con las caracteristicas extrañas! que luego hay problemas.