Logging Frameworks

This is a quick survey of logging frameworks either used in EOL or which seem like good candidates for use.



The NIDAS utility library contains a home-built logging interface. It is self-contained, and it could be possible to adopt it underneath logx to replace other software's dependency on log4cpp. That would go a long way towards trimming down the number of logging frameworks in use in EOL, and maybe the NIDAS log library would see more development if it were more widely used.

  • in-house
  • simple active() check before generating message
  • can be completely compiled out
  • fixed set of metadata: time, level, file, function, line, tag,
  • not hierarchical
  • only single output logger available, either syslog or stream
  • multithread only
  • fixed format, but fields can be suppressed


As of Boost 1.54, the Boost library has an official logging framework:


  • any metadata
  • filter on any metadata
  • threading supported by templates
  • support wide characters
  • formatters associated with each sink
  • built-in syslog, stream, and rotating file backends
  • built-in timers
  • short-circuits message generation without calling a test function



  • widely-used, familiar, portable API (based on Java log4j)
  • categories
  • hierarchical
  • some standard configuration options and output formats supported (eg, xml)
  • particular implementation we've used is not under active development
  • Nested Diagnostic Contexts

In EOL, the logx library is a thin wrapper to log4cpp. It adds convenience methods for things like command-line options and a module-scope logging category instance with the LOGGING() macro. logx also adds scoped logging: the ability to log a message when an object comes into scope and then when it leaves scope.

log4cxx (Apache)


I do not know of any uses in EOL, but anything from the Apache project seems worthy of consideration. It is based on the log4x API, and it should be very portable.

  • requires APR
  • under active development
  • Nested Diagnostic Contexts
  • built-in configuration


I believe the de facto standard for Java, with concepts like Loggers, Appenders, Layouts, and Categories.

For Further Thinking

Logging should never be compiled out. If you need it during development, someone else will need it in development, and they should not have to recompile the tree with new cpp symbol definitions just to get new diagnostic logging. If it's useful during development, it will likely be useful for testing and diagnostics on operational code, but only if the logging was left compiled in. A good logging framework allows expensive message generation to be skipped if it will not be logged.

Rather than sending messages with statistics, send the statistics and let the consumer format. Sometimes consumer needed to print to a file or terminal, sometimes it was a GUI needing to fill in a label. Plus it saves space to send just the numbers. This introduces the idea of deferring formatting as long as possible, instead allowing attributes to logged which can be retrieved and handled later in some custom manner. The boost::logging library provides this kind of functionality.

It seems like logging and messaging and monitoring should converge to use the same mechanism. If there's some point in the software with valuable information to report, then the distinctions between a log message and an event publication and a status message become arbitrary.

Other features for which we've had a need: automatic or configurable throttling, dynamic run-time configuration, stack traces, inventory of log points (probably best generated by scanning the source).