Concurso De Programacion

[sés]

ses: no cumple la regla de las diagonales.

¿Por qué no la cumplo? He probado mi código con MingW y funciona perfectamente.

Ahora lo he probado también con Borland y también funciona.

Con Visual C parece que falla (pero no solo las diagonales) y, a mi entender, es por un fallo del compilador. Me explico:

Los parámetros en las llamadas a funciones se meten en la pila de derecha a izq.

La llamada:
 f( 1, 2 );

Debería ser algo como:
 push  2
 push  1
 call f

Dicho de otra forma:2
f( expr1, expr2 )

sería:
 
 push expr2
 
 push expr1
 call f

Visual C  está calculando expr1 (en mi caso ++i%N) antes de evaluar la expresión de la derecha. Eso para mí es un fallo del compilador.

De hecho, si en mi código cambias el printf por esto:

Código [Seleccionar] Expand

printf((i+1)%N?"%-3d":"%d\n",(i*2-i/N)%N*N+(N/2+i-i/N)%N+1),i++
Funciona perfectamente en Visual C


P.D.: ...¿o será que están mal el resto de compiladores? O.O

[sés]

 Ejem...
Fallo en Visual C

Definitivamente considero que mi código es correcto por que no tiene nada extraño. Es C normal y corriente, y el que un compilador haga cosas raras no lo hace menos válido.

En las reglas tampoco dice que deba funcionar con todos los compiladores. Si uno, como es el caso de Visual C, se hace un lío con una expresión, no es problema del código. Y dado que funciona en más compiladores de los que falla (solo VC)...

[gdl]

 

Ejem...
Fallo en Visual C

Definitivamente considero que mi código es correcto por que no tiene nada extraño. Es C normal y corriente, y el que un compilador haga cosas raras no lo hace menos válido.

En las reglas tampoco dice que deba funcionar con todos los compiladores. Si uno, como es el caso de Visual C, se hace un lío con una expresión, no es problema del código. Y dado que funciona en más compiladores de los que falla (solo VC)...

Vamos a ver.

Una cosa es que se cumpla la norma ANSI y otra que el código sea portable.

La norma ANSI dice en el apartado 6.5.2.2 relativo a las llamadas a funciones, en su párrafo décimo que

10 The order of evaluation of the function designator, the actual arguments, and
subexpressions within the actual arguments is unspecified, but there is a sequence point
before the actual call.

Es decir, que cada compilador puede hacer lo que le de la gana y sigue cumpliendo la norma. ¡Incluso el comportamiento tan extraño del VC! Ya que el párrafo habla no sólo de expresiones sino también de subexpresiones.



Creo que para aclarar las cosas respecto a los fallos, hemos de hacer una clasificación de los mismos. Propongo la siguiente

- Fallos sintácticos: no compila según la norma ANSI.
- Fallos semánticos: existe un fallo en el programa que se puede detectar sin ejecutarlo y basándose en la semántica que da la norma ANSI (tomando un caso favorable si se especifica comportamiento indeterminado).
- Fallos de portabilidad: aparecen cuando se usan características que la norma ANSI deja indefinidas o deliberadamente abiertas.


El caso de sés entra dentro de un fallo de portabilidad ¡¡pero todos los programas tienen fallos de portabilidad!! ¡¡La norma deja indefinido el tamaño de los tipos básicos!! Bastará compilar cualquier solución del concurso para (por decir algo) un PIC16F876 que es un micro de 8 bits e introducir como dimension 259 = 256 + 3. Como es de 8 bits, no puede guardar el 259 y se queda con el 3... que cuela como válido. El programa habría aceptado un 259 y no ha acabado prematuramente. (Y si con 8 bits funcionase... buscamos micros de 4 bits que también los hay :P )

Es más, las reglas dicen que el programa siga la norma ANSI, no que sea portable.

No se han dado casos de fallos sintácticos, pero sí de fallos semánticos. Por ejemplo, el caso de Cronodragón. Es un programa que vuelca por pantalla el fichero que se le introduzca. Sin ejecutar el programa se puede decir que no se está haciendo la comprobación de que se haya introducido un número impar entre 3 y 9.

Creo que esta forma de juzgar los programas sin compilarlos ni ejecutarlos en una plataforma específica debe ser la que se use. A partir de ahora no valdrá decir "el programa falla porque lo compilé con un GENC en un Spectrum 16K y no va". Habrá que decir "el programa falla porque la guarda del bucle es falsa cuando la variable a es 13".

[sés]

 Bueno, a eso es justo a lo que voy. Yo considero mi programa válido porque en ningún momento se especifica que deba funcionar en tal o cual compilador.

Otra razón por la que lo considero válido es porque solo ha fallado en un compilador. Que mucha gente lo utilice no significa nada. También mucha gente usa GCC o MingW y en ese sí funciona.

[sés]

 Probado también con Digital Mars C/C++ Compiler Version 8.42.
Parece que solo va a fallar con Visual C :P


-= EDIT =-
También funciona con Open Watcom 1.3

[Mars Attacks]

 Pogacha, te falta el include obligatorio ;)

[Pogacha]

 En realidad no participé y no se las reglas finales, algunos retoques y es la solucion optima.-
Saludos

[JuanK]

 Bueno el hecho de que sea aequitectura I386, no tiene nada que ver
todo es cuestion del compilador que es qel que a la final estructura el codigo de mauina como mejor le convenga.

Para proximos concursos creo que seria necesario imporner el uso de un compilador determinado para evitar estos incovenientes.


el io lo probe en gcc para MINIX y funciona y no se revienta pro nada del mundo!!  (genial)


jejejeje es broma , pero podria pasar

[sés]

 Ganador del Concurso MQO

(uoh)  

[CoLSoN2]

 LOL

Felicidades :D

[zupervaca]

 la verdad es que es la cosa mas ilegible que he visto, pero ole tus webs por ganar y tener un hijo asi, felicidades  (ole)  

[Haddd]

 Enhorabuena  (ole)  

[JuanK]

 Brillante ses  (ole)

Recien entiendo lo corto de tu solucion, te felicito!!!  (ole)

me has enseñado mucho con eso que hiciste en el printf, la verdad no se me haia ocurrido  :)

Y como hallaste ese algoritmo tan corto para la solucion?  (uoh)  (genial)  

[_Grey]

 MIERDA! ! ! !

digo..... felicidades.

joer, y con solo 2 variables......

[vincent]

 Felicidades tio!  (ole)