From: Cliff Green (cliffg_at_[hidden])
Date: 2007-08-24 13:51:30
One requirement (imo) that seems to be missing or is
under-emphasized is the following:
-- Provide a simple, light, "compilable away",
low-dependency header / "log source" interface for middle
layer general purpose libraries (e.g. many of the Boost
libraries, or a third party general purpose library).
Both of the current "work in progress" logging libraries
seem to be going full speed ahead with a relatively
full-featured logging facility, satisfying a variety of
needs and requirements. This is good.
But all of the example code and use cases are oriented
towards end application usage. A large part of my software
career has consisted of writing general purpose libraries
and frameworks, where the end applications using my
libraries run in a variety of environments. This is also
true of most of the Boost libraries. So the "BOOST_LOG"
interface should be usable in any library (including a few
in Boost where it would be invaluable - e.g. Asio, or
Since a library / function using "BOOST_LOG" might be used
in a single-threaded app, or might be used in debugging
only (where in release mode no logging is desired), or
might be used where high performance and low overhead is
an absolute priority, or might be used in a non-networked
environment, or might be used where "memory only" logging
is available (i.e. there's not a file system available),
"BOOST_LOG" (or its equivalent) should be:
1. Capable of being completely compiled away.
2. Bring in the absolute minimum set of dependencies.
3. Be completely "sink agnostic" - i.e. the output of the
logging can be configured to go to any of a number of
potential sinks, including no sinks.
4. Be very performant - if logging is present but no sinks
are turned on, the overhead should be very small (ideally
cost no more than an if statement or two). Mutex locking
for multi-threading should not be performed unless logging
in a multi-threaded environment (or a threaded sink /
service) is turned on.
Configuration of the logging environment - e.g. which
sinks are turned on, which optional attributes are turned
on, etc, should be a different set / layer of Logging
functionality, separate from the "BOOST_LOG" / log source
client interface. The end application (or some higher
library layer) controls this aspect.
The logging implementations so far seem to be "code only"
instead of concentrating on the rationale, use cases, and
client interfaces. I think there's danger of another "log
library rejection" without some "stepping back and
re-thinking" (and I've forgotten most of the original log
library review comments - I should go back and re-read,
since I'm sure I'm repeating comments already said).
I'll be happy to add any of these comments to the Wiki
Boost Log area - let me know (I can also assist with
library requirements and design - I've designed and
developed at least two logging libraries in past
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk