Sobrecarga de funciones C++

[swapd0]

Estoy programando una serie de librerias y como hay partes donde necesito manejar angulos en radianes, en otras partes en grados y en otras en ¿grados centesimales? (0..100 -> 0 .. 90º). Se me ha ocurrido hacer algo asi.

Código: [Seleccionar]

typedef float acimut_t; ///< 0 ... 400
typedef float grados_t; ///< 0 ... 360
typedef float radianes_t; ///< 0 ... 2*pi

El problema es que no puedo hacer lo siguiente, me dice que grados esta redefinido con otro tipo.

Código: [Seleccionar]

grados_t grados(acimut_t v)
{
return (v / 400.0) * 360.0;
}

grados_t grados(radianes_t v)
{
return (v / 2*kPi) * 360.0;
}

Todo este rollo lo monto porque mas de una vez he mezclado grados con radianes y la idea es que el compilador me avise por no estar definido grados_t + radianes_t

¿Alguna idea de como hacerlo, hay alguna otra solución mejor?

[Ruben]

Hi,
typedef crea un alias pero no define nuevos tipos. El compilador se queja porque, efectivamente, has definido dos metodos con mismas declaraciones. Vamos, que el compilador se encuentra con un acimut_t en una y, al ser un alias de un float, para el compilador es un float. Lo mismo pasa con radianes_t. Asi que, el compilador ve dos metodos iguales.

Por mi experiencia, normalmente no se diferencia explicitamente en codigo que tipo de angulos usas. Normalmente, se menciona en la documentacion y los argumentos se pasan en floats. Por ejemplo, para que te hagas una idea, en directx la funcion de creacion de una matriz vista pide radianes? (nunca me acuerdo! ) para el fovy y en glu se usa el contrario (grados? ), pero ambos esperan un float. Luego, con que te definas un par de constantes de conversion, vas listo.

Ahora, yo lo que haria (por tu propia salud mental! ) es homogeneizar el tipo de angulos que usa tu codigo. Es decir, decides que tu codigo usa radianes y luego ya vas convirtiendo como prefieras (wrappers, cambios in-situ, etc...) de los tipos de las librerias al tuyo.

Espero que te haya servido.

Un saludo,
Ruben

EDITADO: corregidas algunas faltas y errores.... 

[swapd0]

Ahora, yo lo que haria (por tu propia salud mental! ) es homogeneizar el tipo de angulos que usa tu codigo. Es decir, decides que tu codigo usa radianes y luego ya vas convirtiendo como prefieras (wrappers, cambios in-situ, etc...) de los tipos de las librerias al tuyo.

El problema es que desde el punto de vista del usuario se debe trabajar con angulos de 0 a 400, pero si tengo que calcular algun seno o coseno tengo que usar radianes, y en openGL los angulos van en grados...

Asi que lo que quiero es que si tengo clases donde los ángulos van a ir de 0 a 400 el compilador me avise (por si se me pasa) si le paso un radianes_t...

Mas que nada es para que me sea imposible meter la pata y mezclar angulos distintos.

[Ruben]

Hi,
mas o menos, por lo que puedo intuir de tu caso, yo lo que haria seria trabajar en un tipo de angulo en mi "core" y pasaria (lo antes posible) todas las entradas/salidas de angulos que lleguen/salgan a/de mi "core". Por ejemplo, supongamos que mi core trabaja en radianes. Si el usuario trabaja en grados de 0..400 justo despues de recoger la entrada del usuario y validarla, la convertiria a radianes, para despues procesarla en mi core. Con Opengl igual, justo cuando vayas a necesitar llamar a Opengl, lo conviertes a grados.

Yo no creo que merezca la pena meter mas tipos en este caso.

Un saludo,
Ruben

[Hechelion]

Hi,
mas o menos, por lo que puedo intuir de tu caso, yo lo que haria seria trabajar en un tipo de angulo en mi "core" y pasaria (lo antes posible) todas las entradas/salidas de angulos que lleguen/salgan a/de mi "core". Por ejemplo, supongamos que mi core trabaja en radianes. Si el usuario trabaja en grados de 0..400 justo despues de recoger la entrada del usuario y validarla, la convertiria a radianes, para despues procesarla en mi core. Con Opengl igual, justo cuando vayas a necesitar llamar a Opengl, lo conviertes a grados.

Yo no creo que merezca la pena meter mas tipos en este caso.

Un saludo,
Ruben

+1

Te iba a dar la misma idea, pero arriba esta perfectamente escrito, así te ahorras dolores de cabeza y errores.

[swapd0]

Al final me voy a decantar por trabajar en un formato y hacer la conversión al leer los datos, a fin de cuentas es la solución mas simple y hay mas personas de acuerdo con ese sistema.

gracias

[kraj0t]

A mí se me ocurre otra cosa que podrías hacer. Definir una clase para cada uno de los tres tipos que comentas, p. ej: Grado, Radian, Gradian (sí, se llama así). Entonces, para cada una de las clases, defines operadores de conversion implicita (operator=). Claro que tambien tendrías que definir los operadores +, -, * ....

Ogre, la librería de gráficos, hace esto mismo. Existe la clase Radian y la clase Degree, y ambas son intercambiables de manera automática gracias a esos operadores. Puedes ver el código en este fichero. Prácticamente te diría que copiaras ese código y lo usaras. Donde pone Real, cámbialo por float. Sí, de esta manera lo tendrías ya hecho. Ah, y no te preocupes, es Open Source :-)

De todos modos, mi consejo es que te líes a hacer esto sólo si ves una utilidad grande, o si te vas a divertir haciéndolo/aprendiéndolo. Porque como ya te han dicho Ruben y Hechelion, realmente no es una funcionalidad muy importante, nada que no puedas controlar de manera sencilla.

[swapd0]

A mí se me ocurre otra cosa que podrías hacer. Definir una clase para cada uno de los tres tipos que comentas, p. ej: Grado, Radian, Gradian (sí, se llama así). Entonces, para cada una de las clases, defines operadores de conversion implicita (operator=). Claro que tambien tendrías que definir los operadores +, -, * ....

Esto era justo lo que no queria hacer, por eso probé lo de los typedef, pero no funcionaba.

De todas formas, no me parece mala opción despues de ver que el ogre también la usa, ademas haciendo como dices la conversion implicita me evito problemas por mezclar formatos.

Gracias por lo de gradian, queda mejor que acimut