Orden de los llamadas, ejecucion en Release o en Debug

[tamat]

Resulta que en mi cargador de meshes cuando lo ejecutaba en Release el modelo salía orientado de manera distinta de cuando lo ejecutaba en Debug.

Despues de culpar a camaras, shaders y arbol de escena me doy cuenta de que el error está en el cargador, y el problema es el siguiente:

Código [Seleccionar] Expand

p.set(file.GetFloat(),file.GetFloat(),file.GetFloat());

Esta linea donde extraigo tres floats para cada componente se ejecutaba en diferente orden en Release y en Debug, lo que hacía que la X y la Z estuviesen intercambiadas segun cómo se compilaba.

Ahora ya lo se y hago las llamadas aparte en lugar de hacerlas directamente en el parametro pero para no olvidarme de este posible fallo me interesaria saber si realmente es así siempre, y si existe algun motivo para ello. No acabo de entender qué motivo podría haber para invertir el orden de ejecución de los parametros.

Gracias.

[TheAzazel]

suena a visual studio no?

de todos modos es rarisimo :S

[ethernet]

Suena a tema de optimización. Quizás en debug lo haga tal cual tú lo planteas y en release haga sabe dios cual optimización.

EDIT: si miras el standard pag 68 (http://www.ishiboo.com/~nirva/c++/C++STANDARD-ISOIEC14882-1998.pdf ) dice:

The order of evaluation of arguments is unspecified...

[MrK]

A mi me suena mas a 'calling convention', que no sea que lo tengas diferente es debug que en release

http://en.wikipedia.org/wiki/X86_calling_conventions

De todas formas es raro, puesto que diria que solo la 'convencion pascal' pasa los parametros al reves...

En el msvc6 esta en c/c++, code generation

[tamat]

Gracias por vuestras respuestas.

[sés]

Una cosa es el orden de paso de parámetros, que no va a cambiar, y otra muy distinta es el orden de evaluación de esos.

Mejor evitar problemas:

Código [Seleccionar] Expand

float f1 = file.GetFloat();
float f2 = file.GetFloat();
float f3 = file.GetFloat();
p.set( f1, f2, f3 );

Esto ya me surgió con el "famoso" concurso del Cuadrado Mágico. Creo recordar que todos los compiladores lo hacían igual excepto VC, que hacía lo que comentas.

[Marci]

A mi me pasó lo mismo usando el Builder y al final acabé haciendo lo mismo que propone sés. Parece que solo ocurre cuando le pasas a una función parametros que son llamadas a otras funciones. Alguien sabe si podría ser algo relacionado con la creación de variables temporales

[sés]

Es simplemente lo que puso ethernet:

The order of evaluation of arguments is unspecified...

El compilador debe evaluar los parámetros y pasarlos en un orden. Y la única obligación que tiene es la de pasarlos en el orden correspondiente, dependiendo de la convencción (C, PASCAL...). El orden de evaluación ya es cosa de cada uno.

No es algo a lo que haya que darle vueltas, cada uno lo hace como quiere... y además es libre de cambiarlo en cualquier versión del compilador.