Re: [boost] Boost Logging library - first draft

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-01 20:08:07

Hello JD,

Sunday, April 1, 2007, 12:47:04 AM, you wrote:

> Hello,

>    So here is the question:
>         "Is there any interest in a logging library for boost?"

>    John Torjo did not answer my mail, beside I looked at pantheios. it
> seems a little bit complex... My idea is that a logging library should
> be _simple_ to use.

>    Here is a small example:

[snip]

>    You can find the first draft of a logging library in the boost 
> Sandbox vault. It consists of a header files, some examples and 
> documentation. Put the file at your boost root folder and unzip it.

>    It compiles with msvc and vc-8_0. I'll try with gcc asap.

>    So let me know if you think it worth something or not.

I've took a quick look at the implementation and the docs of the
library.

First, I'd like to thank you for performing this analysis of previous
proposals attempts. You did a great job of summarizing all opinions
and suggestions were made which helps to better understand the
requirements to this kind of lib.

Now to the point. I understand and agree that the logging library
should be simple to use but I see no reason we should sacrifice the
extensibility for it. To my mind a carefully designed library
interface is the way to go, not the functionality and extensibility
limitation. And unfortunately, I see little ways of extension of your
implementation to get the functionality I got used to. I may be wrong
and may have missed something.

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
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.
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).
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".
4. The library is header-only, which will raise some problems in a
complex applications that consist of more than one module. The logger
instance will be visible only in one module, other modules will have
their own loggers, which obviously mean problems with their
initialization (which streams to add as "sinks"?). I believe that
logging library should be implemented as a shared lib.
5. I think there are too many macros in the interface. I'd rather have
BOOST_LOG as an inevitable minimum, but no more than that.

If you are interested, I could describe my view of architecture of
such logging library (I'm working on the implementation on an early
stage). Though, I think, many of us already have such view in our
minds and maybe have it implemented.

And finally some implementation-regarded notes (though I understand
this was just a draft, I couldn't hold myself, sorry :) ):
1. The logger is default-constructible from the user's code, but it
seems that you intended to make it singleton.
2. logger::get_instance is not thread-safe - function-scope statics
are used.
3. You should not define namespace bl = boost::logging; in the library
code.
4. Element global operators should be in boost::logging namespace.
They will be reachable via ADL.
5. Each logging record involves std::stringstream (even not
ostringstream) construction, formatted output copying, and
destruction. I'm afraid, that would be a performance impact on the
application.
6. I believe, some of the "Logging typedefs declarations" might have
been hidden into the logger class and renamed. Some other names (like
null_deleter) might have been hidden to an internal namespace.

PS: I hope I didn't kill your encouragement with my reply. This is the
last thing I'd wanted to do.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]