Re: [boost] thoughts on logging library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-04-08 15:33:18

Although I'm not the author of the library in the review queue, I'm 
working on my own library and would like to share some thoughts on this.

Christian Holmquist wrote:
> 
> First of all, I think that a boost logging library should come up with
> one, and one only, way of expressing a log line.
> 
> BOOST_LOG(some, kind, of, args);

Agreed, the simpler the interface is, the easier to learn the lib.

> Now, how should the interface of BOOST_LOG(...) look like? To find
> that out, I'll start by explaining how I would like boost log to
> behave from a users point of view, for instance using boost.Asio.
> 
> #define BOOST_ASIO_LOG_ENABLE
> #define BOOST_ASIO_LOG_MIN_LEVEL boost::log::level::debug
> #include <boost/asio/asio.hpp>
> 
> // Insert lots of broken client code here... =)

[snip]

> So, I've only informed the libraries that I want log to be generated,
> not anything about where it'll end up, or what kind of information
> it'll contain. The author of Asio also doesn't know what kind of
> information that will be generated either, but can, and should, only
> provide what is available from the library's point of view.

Although it looks very tempting, I have two concerns about it:
1. Such configuration macros tend to introduce ODR violations. This 
problem probably won't get in the way in scope of a single executable, 
but what if the application consists of a dozen of them? It gets worse 
in case if the Boost library is compiled into binary itself.
2. Recursive calls can become a real issue. Assume that I want to send 
logs by network using a sink based on Asio. Trying to log from Asio 
would be impossible. The only solution I imagine right now is to detect 
such recursive calls in the logging library and filter away logging 
records from inside processing of other logging records.

IMHO, the first issue is not very special for logging. There are quite a 
lot of various configuration macros of different Boost libraries and yet 
there are no common means to define them _both_ when building the Boost 
itself and user-side applications except to manually add them to every 
compiler command line. I think a common user configuration header file 
is needed to address this problem.

[snip]

> Is this along the line what boost.log has in mind, or will it be a
> logging library not to be used by the boost libraries themselves?

I think, making Boost libraries able to write logs is definitely worth 
thinking of, although it may not be the top priority feature. IMO, we 
should first provide users with ability to easily write logs. We can add 
logging to boost libraries at a later stage.