Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-08 07:29:37

On 03/08/2010 03:00 PM, strasser_at_[hidden] wrote:
>
> could you please explain your design rationale for:
>
> - not using user-defined log record types.
>
> for example:
>
> logger << http_connection_requested("Connection from foreign
> host",host,port);
>
> with http_connection_requested being a user-defined class that models a
> defined concept so that the logging core is able to extract the attributes.

That exact syntax is not possible because the streaming expression is 
executed after the record is constructed. Although the topic differs, 
the reason is the same as described here:

http://tinyurl.com/ydlncuv

As for the absence user-defined implementation of log records, there are 
two reasons:

1. I never thought about it, and thinking about it now I don't see a use 
case for it.
2. Log records are created by the logging core, and it cannot create a 
user-defined type now.

> - your use of shared_ptr. shared_ptrs are used in places where you'd
> expect return by reference(e.g. core::get()) or by value(e.g. result of
> Attribute::get_value()).
> why is a singleton managed by a shared_ptr?

In case of singletons, this solves the problem of global objects 
destruction order. For example, all loggers store a shared_ptr to the 
core, so if you keep a logger object longer than the core life time, it 
will still be functional.

In case of attributes, the pointer returned by get_value refers to a 
polymorphic object (in some cases - to the attribute itself). There is 
no way to return this object by value as its actual type is hidden 
behind the attribute_value interface.

> - why is the logging core a singleton? should you not be able to set up
> multiple logging systems within an application, each with its own
> filters and sinks?

1. I don't see a use case for such a set up.
2. This would complicate the library usage considerably. For example, 
when constructing a logger one would have to specify a core instance to 
work with. There are other places which would require similar interface 
changes.

> - for identifying attributes by runtime strings, instead of statically
> e.g. by attribute tags.

Well, strings looked simpler and more natural matter for a key type in 
attribute sets. A completely static solution is not viable because it 
would require templating the whole library on the attribute set type, 
which in turn would ruin modular architecture and increase compile times 
dramatically.

> - identifying channels by runtime strings

Strings are just a default. You can use another type to identify channels.

> - special handling of severity. why is it not just another attribute?

It is.

> - special handling of message. why is it not a string attribute?

Because the message string is composed after all attribute values are 
acquired from the attributes. The link I gave above should give the answer.