Re: [boost] Logging Library -- Formal Review Request

From: Andras Erdei (aerdei_at_[hidden])
Date: 2005-05-01 16:50:00

> John Torjo wrote:

> > I've just updated the Boost Log Library:
> > http://torjo.com/code/logging-v132.zip

* How much effort did you put into your evaluation?

I've only read the documentation, not tried the library (i have
given a quick try to a previous version, but that was long ago).

* What is your evaluation of the potential usefulness of the library?

A logging library is a must have, just like a multi-threading and
a windowing library, but i am afraid that developing a one size
fits all logging library is not much simpler than doing so for these
other two. This library is already much better than most i have seen,
but it is not useful for me without several changes.

* What is your evaluation of the documentation?

It is too brief.

* What is your evaluation of the design/implementation?

I would like to see three components:

- the viewer application on John's page should be officially part
  of the library, with the option of running it as a separate
  application/running it as a thread in the application being
  developed

- the current libary should be split into a logging primitives
  (building blocks) part

- and into several "..._style_log.hpp" interfaces, supporting the
  different styles and bells & whistles and different default
  settings people ask for

My main concern about logging is that it changes application
behaviour: often there are bugs that only surface in release code
because logging is slow and it introduces synchronizing, so logging
should be as fast as possible, and locks should be avoided whenever
possible.

My style would be:

Appenders: do not cache and do not use a dedicated writer thread,
but each thread automagically creates it's own separate logfile.
The files are kept open, flushed after each log entry, and the
streams used for formatting the log entries are kept and reused.
The log files are created in a system-dependent directory (e.g.
%TEMP% on windoze), and the logs from the previous run are removed
automagically.

Modifiers: a global counter prefix, an indenter and a clock (secs
elapsed since application start); and source file name, line number
postfix.

I do not want to declare and define and initialize logs, just
include a header, and then write "LOG << ..."; i do not want
to give names to logfiles, and i don't want runtime configurable
logs and log levels and multiline log entries and calling functions
that log from inside "LOG << ..." statements and i do not want to
pay (with runtime and additional typing) for the features i do not
use.

I think a lot of the current library functionality can be moved
into the viewer: it can merge the per-thread logfiles or scatter
log entries based on a prefix (thus no need for named logs and
different threads writing the same file), it can calculate entry
times from the file creation date and clock stamp (to avoid time-
consuming date formatting modifiers) etc. Also, having indentation
in the logs allows the viewer to display the log contents as a
tree-view making log browsing much simpler.

* Do you think the library should be accepted as a Boost library?

Not yet, i would rather put a link and a strong suggestion to use it
on the boost webpage, and include it in boost only after it has been
used in several projects.

br,
andras