estoy usandoboost::log como un registrador para mi programa de C ++. Durante el desarrollo, a menudo lo uso de esta manera, por ejemplo:

#define LOG(severity) BOOST_LOG_SEV(boost::logger::get(), (severity))
#define LOG_ERR LOG(Severity::error)
#define LOG_INFO LOG(Severity::info)
#define LOG_DEBUG LOG(Severity::debug)

dóndeBOOST_LOG_SEV es la facilidad provista porboost::log, mientrasLOG, LOG_ERROR, LOG_INFO, LOG_DEBUG Son atajos definidos por mi.

En breve,BOOST_LOG_SEV compara dinámicamente la severidad de depuración actual con la severidad pasada a la macro misma para decidir si emitir o no la salida.

Este es un ejemplo de un programa que usa las macros anteriores para propósitos de depuración:

// set at compile time
#define MAX_LOG_SEVERITY Severity::debug

int main() {
   // Print all the messages with a
   // Severity <= MAX_LOG_SEVERITY defined before compiling
   boost::log::set_severity(boost::logger::get(), MAX_LOG_SEVERITY); // set_severity() is fictitious just to give you an idea

   // bool err = ...
   if (err)
      LOG_ERR << "An error occurred";
   else 
      LOG_INFO << "Okay;
   LOG_DEBUG << "main() called";
}

Ahora, al lanzar el programa para un entorno de producción, depurar mensajes con unSeverity::debug Nivel realmente no tiene sentido. Podría ocultarlos de la salida simplemente disminuyendoMAX_LOG_SEVERITY aSeverity::info, pero el problema es que las llamadas realizadas porLOG_DEBUG No se eliminará del código ejecutable. Esto tiene un impacto negativo tanto en la eficiencia como en el tamaño del objeto.

El código está lleno de declaraciones de registro y realmente me gustaría preservar el uso simple deoperator<<().

Sin tocar esas afirmaciones, ¿hay alguna mejor definición de macro / truco paraLOG_DEBUG eso haría que el preprocesador o el compilador (durante sus optimizaciones) "omita" o "elimine" las declaraciones de depuración cuandoMAX_LOG_SEVERITY se establece en elSeverity::debug constante?