ja używamboost::log jako logger dla mojego programu C ++. Podczas rozwoju często używam go w ten sposób, na przykład:

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

gdzieBOOST_LOG_SEV to obiekt zapewniony przezboost::log, podczasLOG, LOG_ERROR, LOG_INFO, LOG_DEBUG to skróty zdefiniowane przeze mnie.

W skrócie,BOOST_LOG_SEV dynamicznie porównuje aktualną istotność debugowania z istotnością przekazaną do samego makra, aby zdecydować, czy emitować dane wyjściowe, czy nie.

Jest to przykład programu, który używa powyższych makr do debugowania:

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

Teraz, po zwolnieniu programu dla środowiska produkcyjnego, debuguj wiadomości za pomocąSeverity::debug poziom naprawdę nie ma sensu. Mogłem je ukryć przed wyjściem po prostu zmniejszającMAX_LOG_SEVERITY doSeverity::info, ale problem polega na tym, że połączenia wykonywane przezLOG_DEBUG nie zostanie usunięty z kodu wykonywalnego. Ma to zły wpływ na wydajność i rozmiar obiektu.

Kod jest pełen instrukcji rejestrowania i naprawdę chciałbym zachować proste użycieoperator<<().

Czy nie ma lepszej definicji / sztuczki makro bez dotykania samych tych stwierdzeńLOG_DEBUG co spowodowałoby, że preprocesor lub kompilator (podczas jego optymalizacji) „pominą” lub „usuwają” instrukcje debugowania, gdyMAX_LOG_SEVERITY jest ustawiony naSeverity::debug stały?