Я используюboost::log в качестве регистратора для моей программы C ++. Во время разработки я часто использую его таким образом, например:

#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)

гдеBOOST_LOG_SEV это средство, предоставляемоеboost::log, покаLOG, LOG_ERROR, LOG_INFO, LOG_DEBUG ярлыки, определенные мной.

Короче говоря,BOOST_LOG_SEV динамически сравнивает текущую серьезность отладки с серьезностью, передаваемой самому макросу, чтобы решить, следует ли выводить выходные данные или нет.

Это пример программы, которая использует вышеупомянутые макросы для целей отладки:

// 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";
}

Теперь при выпуске программы для производственной среды отладка сообщений сSeverity::debug уровень не очень имеет смысл. Я мог бы скрыть их от вывода, просто уменьшивMAX_LOG_SEVERITY вSeverity::infoНо проблема в том, что звонкиLOG_DEBUG не будет удален из исполняемого кода. Это плохо влияет как на эффективность, так и на размер объекта.

Код полон операторов логирования, и я бы очень хотел сохранить простое использованиеoperator<<().

Не касаясь этих утверждений, есть ли лучшее определение макроса / трюк дляLOG_DEBUG это заставит препроцессор или компилятор (во время его оптимизации) «пропустить» или «удалить» операторы отладки, когдаMAX_LOG_SEVERITY установлен наSeverity::debug постоянный?