|
Boost : |
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk