Fallo En Visual C

[sés]

 Cuando algunos decían que mi código del cuadrado mágico fallaba, lo primero que se me pasó por la cabeza fue un "coño, ¿fallará en Visual C?", ya que es el más utilizado.

Probé con VC y... anda, si falla. Pero si funciona con MingW, que raro... probaré con Borland. Vaya, pues con Borland también funciona. Que cosas.

Así que he hecho este pequeño programita:

Código [Seleccionar] Expand

#include <stdio.h>

int main( int argc, char **argv )
{
  int i = 0;
  printf( "%d, %d, %d\n", ++i, ++i, ++i );
  return 0;
}

Programa tonto donde los haya... que hace fallar al VC.

Con MingW y Borland, esto imprime: 3, 2, 1
Con Visual C.... ¡3, 3, 3! :blink:

Sin comentarios.

¿Alguien tiene otro compilador a mano? Yo solo tengo el viejo Watcom por ahí, a ver si lo encuentro y lo pruebo.

[Sacrifai]

 http://imageshark.ath.cx/0815/111839671242...4fb16720f8e.JPG

Ehhmmmmm...Uhmmm...

¿Que versión de Visual C++ usais?

PD: Siento que la imagen sea jpg y no png (ocuparía mucho menos) pero es que por alguna razón no me deja hospedar png.

[Warchief]

 A mí en este caso me da 3,2,1. Pero sí recuerdo que cuando yo metí un código parecido para lo del cuadrado mágico me fallaba en un sentido como dices. Creo que era al hacer printf(--j?"algo":"otro"); o alguna cosa parecida, y probando con el gcc en linux si me funcionaba el mismo código. Algo sí está mal con el vc6 sobre esto, pero como digo tu código me da 3,2,1.

[fiero]

 A mi tambien me da "3, 2, 1" , tengo VC 6.0

un saludo

[sés]

 Compilar en "Release"

[ethernet]

 Eso no es para nada un error, el problema que ese tipo de operaciones no tienen una forma definida en el standard y por lo tanto cada compilador lo hace como le viene en gana, aunque la verdad la forma lógica es la del borland.

saludos

[Sacrifai]

 En Release sigue dandome correcto.

[Mars Attacks]

 Ethy ya lo ha dicho, en C no está definido el funcionamiento del pre/post/incre/decremento en el cuerpo de una instrucción. Depende del compilador, el **cremento se ejecutará al terminar la sentencia completa, o nada más leerse, o incluso si se usa en llamadas a funciones cuando acabe la función o antes de entrar en ella.
Es "peligroso" confiar en eso.

Edito: gdl ya se ha marcado un peacho explicación en otro hilo XD

[_Grey]

 Si el standard de c no dice nada de esto, habra que comformarse.

De todas formas no se por que lo "normal" a de ser el metodo de borland, mirando lo friamente diria que a de dar "1,2,3".

Saludos.

[TheAzazel]

Si el standard de c no dice nada de esto, habra que comformarse.

De todas formas no se por que lo "normal" a de ser el metodo de borland, mirando lo friamente diria que a de dar "1,2,3".

Saludos.

Estoy contigo.... no se pq da 3,2,1.....

[senior wapo]

Si el standard de c no dice nada de esto, habra que comformarse.

De todas formas no se por que lo "normal" a de ser el metodo de borland, mirando lo friamente diria que a de dar "1,2,3".

Saludos.

Estoy contigo.... no se pq da 3,2,1.....

..porque los valores se meten en la pila en sentido inverso cuando se pasan a funciones C puras. Es un convenio que permite que existan funciones con un numero indefinido de parámetros.

El primer parámetro por la izquierda es el último en meterse en la pila, de forma que la función printf sabe siempre que en lo alto de la pila tiene la cadena de formato y que analizándola puede saber cuantos parámetros vienen detrás en la pila.

[fiero]

 Sí, a mí tambien me ha parecido siempre, que lo más natural hubiera sido adoptar el orden normal de paso de parámetros, de izquierda a derecha. Sin embargo, se adoptó como "standar" el paso de parámetros a lo PASCAL, o sea al revés, como explica sés en el otro hilo. Así que por eso sale "3,2,1", los parámetros se evaluan de derecha a izquierda.

En modo Release dá "3,3,3" sólo cuando está activado "Minimize size" o "Maximize speed". El evaluador del concurso debería probar los programas con un compilador que no haga optimizaciones en el código, por si acaso.

un saludo

[ethernet]

Si el standard de c no dice nada de esto, habra que comformarse.

De todas formas no se por que lo "normal" a de ser el metodo de borland, mirando lo friamente diria que a de dar "1,2,3".

Saludos.

teniendo i=0;printf("%d %d %d",++i,++i,++i) en compilador vc++6 hará lo siguiente:

1.- hace los preincrementos: ++i;++i;++i -> i =3;
2.- llama a la función printf("...",3,3,3);

todo esto porque el standard no dice cuando hay que hacer los preincrementos y los postincrementos. vc++ lo hace antes de la función, borlando lo hará antes de pasar cada parámetro. Ya hemos hablado en este foro (y en otros muchos, solo hay que buscar un poco en google) sobre este tema, sobretodo cuando se toca el tema de aritmética de punteros.

saludos

[senior wapo]

Ethy ya lo ha dicho, en C no está definido el funcionamiento del pre/post/incre/decremento en el cuerpo de una instrucción. Depende del compilador, el **cremento se ejecutará al terminar la sentencia completa, o nada más leerse, o incluso si se usa en llamadas a funciones cuando acabe la función o antes de entrar en ella.
Es "peligroso" confiar en eso.

Edito: gdl ya se ha marcado un peacho explicación en otro hilo XD

En realidad si que está definido, solo está indefinido el orden de evaluación en los parámetros de llamada a funciones. Supongo que te referías a eso, solo lo digo por tocar los cojones un poco, que últimamente posteo menos  (twist)  

[fiero]

 vaya.. se me ha colao Senior wapo XD.

Es un convenio que permite que existan funciones con un numero indefinido de parámetros

Esa razón es una buena razón si señor...