Re: [boost] Boost Logging library - first draft

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2007-04-02 21:59:32

On 4/2/07, JD <jean.daniel.michaud_at_[hidden]> wrote:

> There is no way to extend my library as basically it offers all what I
> need and look for from a logging library! :) No kidding.

That doesn't sound like a very good place to start then.

> > 1. The whole design looks more like a stream dispatcher rather than a
> > logging library which has to be more complex. I see no scope logging
>
> Ok so if I understand, and correct me if I'm wrong, a scope logging
> facility would be some kind of macro added at the beginning of a
> function. This macro holds an object (RAII style) that would log the
> function name in its constructor (with eventually arguments) and log the
> exit of the function in its destructor. I'll add it.

Please, don't start with a macro.  Use an object that adds information
about the current scope (e.g. BOOST_CURRENT_FUNCTION, __FILE__,
__LINE__) to a thread-local in its constructor and removes it in its
dtor.  Not unlike boost::scoped_lock.

In some logging code I've implemented at work, I call this a "Tracer".
 These are usable not just at function scope, but inside nested scopes
as well (e.g. you can put one inside a 'for' loop to trace its
execution).  Personally I never end up using them, but some folks
can't live without them.

> > support, no custom log record attributes, no filter or wide logging
> > support, and I see no obvious way to implement these on the user side
> > to plug them into your lib. The way to completely wipe out logging
> > from the user code during compile time would be good too, though it's
> > not very difficult to implement it.
>
> - Log record attributes (what is it? just to be sure of what we are
> talking about.)

I suspect the "standard" tuple of information (some) folks want to
collect for every log message: thread ID, timestamp, filename, line
number, and message.  Perhaps function name as well.

> - filter
> - wide logging (I guess it means internationalization (let's say i18n))
>
> > 2. The logger object is a singleton which, I think, would be
> > inappropriate once I would have custom attributes. I think the logger
> > should be separated from the core library, which indeed would be a
> > singleton. This would not only make attributes possible, but form a
> > "source" concept. A logger would be an implementation of this concept,
> > though allowing other implementations of "sources" (like, a
> > third-party application console interceptor, for example).
>
> For me the logger is the core of the logging library.
> So the source is the logger. It's the object who is responsible to
> collect logs generated by the user? Does he format them?
>
> > 3. The "sink" (or "target") concept is simplified down to a stream,
> > which is not a best choice. Remember that the log record is more than
> > just a string. It consists of a number of parts (attributes) - record
> > number, time, source code location, severity level, and (yet another
> > attribute) message text. There may be other user- or library-defined
> > attributes. And the "sink" should be able to define which attributes
> > to log and how to format them. In fact, a "sink" may apply its own
> > filters to wipe out the unneeded records from the output. This is not
> > possible with a simple stream "sink".
>
> Ok it's clearer now. An attribute is what I call the element of the log.
>   Well I'm using my element_list as a description of the format of my
> logs. In doing such thing as:
>
> "[" >> boost::logging::level >> "] - " >> boost::logging::filename

I think your stream insertion operators are pointing the wrong way.

> Including the header in each library will lead to having two differents
> instance of a logger in my final executable?
> The header-only solution seems so great to me. Include and forget...

This is not good for more complex applications that need to share logs
across different modules.

> std::strstream logger::m_str ?

What about a thread-local stream object that is reused?

> ... I think I took this problem too lightly. We shall not focus on
> implementation at first but more on the requirements. Austin Bingham, in

Requirements are tough, because everyone (including me!) has different
ones.  I think it might be more productive to try and identify the
core concepts required to implement the various requested features and
come up with clear specifications for their interfaces.  Then take
these

> an other post, was also saying that we should first write the minimal
> requirements of the Boost.Logging library on some wiki or whatever... On
> the other hand, from the profile I draw in my summary earlier,
> Konstantin mention log4cpp (http://log4cpp.sourceforge.net) as a
> potential candidate.

I'd argue strongly against basing any Boost.Logging library on any of
the multitude of C++ ports of log4j (of which there are at least
log4cpp, log4cplus, log4cxx).  They are generally bloated, suffer from
a horribly baroque runtime configuration, and do not make good use of
C++ language features.  Some of them are also more or less dead
projects (e.g. Apache's log4cxx's home page mentions that "At this
point, log4cxx-0.9.7 is substantially out of date, has known serious
deficiencies" but no successor version has been released in over two
years.

A clean-room design (which might borrow some concepts from log4*) is a
much better idea IMHO.

> And still, some people propose their homegrown
> libraries... Like everybody here, I have a limited amount of time. I was
> wondering if it would be possible to assemble a small team led by some
> boost authoritative guy (Gennadiy?) to pull this.

I doubt you can impose upon Gennadiy to take this on in addition to
his maintainership of Boost.Test.

-- 
Caleb Epstein