On 03/08/2010 03:00 PM, strasser@uni-bremen.de 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.