2011-12-19 6 views
6

Tengo la función de registro que se llama en varios lugares a lo largo del código. Para cada registro, debo suministrar 2 constantes de tiempo de compilación. Hay 2 enfoques para llevar a cabo:¿Qué enfoque es mejor para suministrar constantes de tiempo de compilación a una función? Argumento de la función contra el parámetro de la plantilla

(1) del argumento de función:

template<typename T> 
void log (const T &obj, const int LINE, const int COUNT) 
{ 
    // T is used for some purpose 
    if(debug) 
    logging(obj.out(), LINE, COUNT); 
} 

llamada como,

log(str, __LINE__, __COUNTER__); 

(2) parámetro de plantilla:

template<typename T, int LINE, int COUNT> 
void log (T &obj) 
{ 
    // T is used for some purpose 
    if(debug) 
    logging(obj.out(), LINE, COUNT); 
} 

llámalo como,

log<__LINE__, __COUNTER__>(str); 

No soy capaz de decidir, porque el primer enfoque ofrece simplicidad, pero estamos pasando constantes en tiempo de compilación. El segundo enfoque es perfecto, pero el tiempo de compilación probablemente aumentaría. Esta tarea es tediosa, y aún no he implementado ninguna de ellas, por lo que no tengo ningún punto de referencia.

Será una gran ayuda si alguien puede responder a esto desde su experiencia/conocimiento.

+1

¿Cómo se define "mejor"? Ambos * trabajan *, entonces, ¿qué criterio usarías para decir que uno es mejor que el otro? –

+0

@NicolBolas, ya que quiero elegir el mejor entre 2 en función del tiempo de compilación y el tiempo de ejecución. También hay una ligera modificación en el código de ejemplo. – iammilind

+0

Cualquiera que sea la función 'logging', * con toda certeza * será más lenta que pasar dos enteros como argumentos. Así que no veo cómo el rendimiento del tiempo de ejecución cambiará mucho en ambos sentidos. Esto suena sospechosamente como una optimización prematura. –

Respuesta

3

Iría con la primera opción. El impacto en el rendimiento de pasar dos enteros es insignificante. El optimizador también probablemente alineará la llamada de función en cuyo caso no habría diferencia entre los dos. La segunda opción, creo, es una mala idea, ya que creará muchas versiones de la misma función, sin ningún motivo.

+0

Bien, hay una ligera modificación en la sintaxis de la pregunta. El 'log' en sí es una función' template', pensé en no mencionarlo ...pero descubrió que sería útil. Además, ¿el compilador no optimizaría las diversas versiones de 'template log' también? – iammilind

+0

Bueno, solo habrá algunas versiones de la primera función de registro, std :: string, std :: wstring, char *, wchar_t *. Mientras que básicamente cada llamada de función a la segunda versión dará como resultado una nueva función. El optimizador probablemente lo manejará, pero obtendrá el mismo resultado con un tiempo de compilación más largo. – ronag

4

Dado que la elección entre estos dos hace una diferencia en el código de llamada, recomendaría el registro a través de una macro. Entonces no tiene que preocuparse ahora por cuál de estos es mejor, porque es fácil cambiar entre ellos.

Una vez que tenga su aplicación real escrita, puede meterse con la definición de macro para comparar los dos. O no, si hay más áreas productivas para optimizar. Si resulta ser una gran diferencia, incluso puede dejarlo abierto para las configuraciones de compilación para decidir si usar -DLOGGING_COMPILES_QUICKLY o -DLOGGING_RUNS_QUICKLY.

Otro beneficio potencial de una macro: se puede organizar que el primer argumento se evalúe si y solo si debug es verdadero. No sé cuál es la interfaz de str, o de dónde vienen esos objetos, pero si cuesta algo producir el valor correcto para pasar a log, y luego log no lo utiliza en el caso sin depuración, entonces eso es un desperdicio potencial de tiempo de ejecución.

+0

Buena respuesta ... La mayoría de las veces, LINE y COUNT no se usarán. ¿Qué alternativa es mejor en ese caso el código de producción de abeto? – iammilind

+0

@iammilind: Si 'debug' es una constante en tiempo de compilación, y la llamada a' log' está en línea, entonces el código emitido probablemente debería ser el mismo, aunque es un problema de QOI. Si desea conocer los detalles de una implementación en particular, verifique el desmontaje. –

Cuestiones relacionadas