Boost logo

Boost :

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_MIN_LEVEL boost::log::level::debug
> #include <boost/asio/asio.hpp>
> // Insert lots of broken client code here... =)


> 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.


> 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.

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