Boost logo

Boost :

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-19 14:49:29

On 5/19/05, John Torjo <john.lists_at_[hidden]> wrote:

> In order to make the Logging lib as usable as it can be, I'd like to
> know what is *your* scenario, when using a Logging lib.

Not sure if this qualifies as a "scenario", but these are my
high-level requirements for a logging framework:

* Easy to select/change output destinations (e.g. stdout/stderr, file,
syslog, etc). Output can be sent to multiple destinations if desired.
 Default will send output to stdout if nothing is explicitly specified
by the user.

* Configurable output format. User should be able to associate a
format with an output destination (where applicable - it may not make
sense in all cases). The current modifier chain does this reasonably

* Channels or topics or keywords. I think various people have asked
for this by one or more of these names, and I like the idea as well.
This can be implemented with separate loggers in the current
implementation, but I'm not sure how I feel about that. It doesn't
feel right to me.

* Severity Levels. Topics have a configurable threshold at or above
which they will output a message; messages of a lower severity are
ignored. Users specify the severity level with each message. This is
orthogonal to the channel/topic/keyword, but should be configurable
by c/t/k or with wildcards (e.g. logger.threshold ("*",
logger::levels::warning); logger.threshold ("net",
logger::levels::debug)). What about user-defined levels?

* Thread-safe. Two threads should never have their messages
intermixed as they would with raw ostream<< operations.

* Logfile rotation. For file-based logs, there should be a way to
configure the framework to . The appenders you included in 1.3.3
implement this.

* Simple interface using ostream::operator<<. If my classes have
streaming support, they should be log-able. Something like:

   BOOST_LOG (logger, topic, level) << message << goes << here


   BOOST_LOG (logger, topic, level, message << goes << here)

* Structured log records. In order to implement thread-safety, there
must understandably be some level of buffering. I like the current
ts_appender with its timed batching of writes, but you lose some
information like the name of the logger to which the message was
originally sent. I think it is imperative that a logging "call" is
able to capture a precise timestamp, thread ID, topic, severity, and
__FILE__/__LINE__ info at time the message is created.

If a data structure is used to represent the message instead of just a
std::string, this information can be captured. Some folks might not
like the overhead associated with timestamping etc., so perhaps this
could be provided through an alternate interface, e.g.:

   BOOST_LOG_RECORD (topic, level, message << goes << here)

would create a structured log_record object fully populated with
thread ID, timestamp, topic, level, etc but

   BOOST_LOG (topic, level, ...)

would create a log_record with only the message, __FILE__ and __LINE__
data initialized (the latter two should cost almost nothing).

* Setup. I'm not enamored of the requirement of declaring & defining
loggers (or using scoped loggers). If the channel & severity concepts
become first class citizens, is there any reason not to have a
singleton logger? Or perhaps a singleton logger could be made
available, and users could provide their own loggers instead if they

Caleb Epstein
caleb dot epstein at gmail dot com

Boost list run by bdawes at, gregod at, cpdaniel at, john at