Log con streams y operador <<

[InExtremaRes]

Basándome en los comentarios del isseu #67 he modificado mi anterior propuesta. La base sigue siendo la misma, pero se diferencia principalmente en:

• Las macros se utilizan en la forma GDE_LOG_INFO("hola" << "mundo"); para admitir la posibilidad de omitir completamente los logs en ciertos modos de construcción.
• Log::init() ya no administra el archivo, si no que pide una referencia a un flujo de tipo std::ostream que debe ser gestionado por el llamador de la clase (más información en la documentación doxygen al inicio de la clase Log). Las principales ventajas de esto es que se puede escribir en archivos, cadenas de texto o en la salida estándar tan solo cambiando el parámetro del método Log::init().
• El parámetro etiqueta se ha eliminado. Se deja la posibilidad de seguir usando la etiqueta con un manipulador de la forma tag("etiqueta"), si bien, aun no está implementada.
• Mientras que aun es el destructor de la clase Log quien comienza la escritura en el flujo (archivo), la responsabilidad de escribir el mensaje recae ahora en una función llamada handler de mensajes, la cual puede personalizarse a fin de personalizar la forma en que los mensajes pueden escribirse. Esta función aun no está completamente terminada.

Si bien, no todo está aun terminado, la clase ya es totalmente utilizable.

El commit es bastante grande, dado que tuve que modificar todas las llamadas previas a GDE::Log:info() para adaptarse a la nueva sintaxis. Además, la documentación de la clase es bastante extensa.

Atento a sus comentarios. Saludos!

[edoren]

Hay un problema con la macro __PRETTY_FUNCTION, es una macro que solamente está definida en GCC. Me pone problemas cuando intento compilarlo con visual. Su equivalente en Visual es la macro FUNCSIG__.

[adrigm]

Habría que añadir al archivo config la definición de una macro genérica

[InExtremaRes]

Estaba convencido que __PRETTY_FUNCTION__ funcionaba también en otros compiladores, pero ya veo que estaba equivocado y no probé la compilación más que en GCC. Si bien, podemos generar macros propias dependientes de la plataforma, por ahora yo recomiendo tan solo omitir el nombre de la función dado que es información bastante prescindible. En un futuro se puede buscar una solución con macros dependientes de la plataforma o lo que sea. Corregiré inmediatamente.