Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-08 08:27:37
On 03/08/2010 03:58 PM, strasser_at_[hidden] wrote:
> Zitat von Andrey Semashev <andrey.semashev_at_[hidden]>:
>> On 03/08/2010 03:00 PM, strasser_at_[hidden] wrote:
>>> - not using user-defined log record types.
>> 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:
> ok, but the issue there is not if the log record can have a user-defined
> type, but at what point the type and the attributes are specified so
> filtering can take place before the message is constructed.
As I said, the record now is constructed by the core, and it cannot
construct a record of a user-defined type. The record, among other
things, also holds some book-keeping data that is used by the library -
the result of filtering in order to be able to feed the record to the
sinks willing to accept it.
> the reason I asked this question is because I think log records need to
> have (type) identity.
I'm still not sure I understand. What kind of identity do you mean and
what purpose would it serve?
> especially for (but not limited to) reading back log records, as was
> discussed when the review was announced.
Now that you mention it, I see the problem of constructing a valid
record on the user's side. Yes, the problem is there, but I think it
should not be difficult to solve it by separating the book-keeping data
and the public data accessible from the record interface. However, I
still don't see the need to create different record types on the user's
>>> - 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.
> you could think of setups that use multiple logging systems for regular
> activity logging, but for the use case of binary
> write-ahead-logging(WAL), which will be the focus of my review, it often
> is a requirement to maintain multiple independent logs in the same
The core doesn't limit the number of logs you can maintain. Just
register as many sinks as you need and set up filtering accordingly.
>>> - 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.
> I think(!) it wouldn't require templating the whole library on the
> attribute set, but the filtering etc. could be instantiated on the
> attributes passed to the logger.
Attribute sets are used in loggers and the core. I don't see how it
would be possible not to template them if some kind of type erasure is
not used (which brings us to the current solution). Further, the core
constructs a view of attribute values out of the attribute sets, which
is basically a map, like attribute sets. This view is then processed by
filters, formatters and sinks, so they will be templated, too.
> my focus here was again WAL. WAL records consist entirely of attributes
> that are dumped in binary form.
I guess, in terms of the library, these would be attribute values.
> I presume attributes are now stored in a std::map<std::string,Attribute>
> or similar. this is not an acceptable performance overhead for WAL.
And what is your suggestion? Use fusion::map? Or
>>> - 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
> ok, I might have mixed up terminology here. I meant the message on the
> user's part, passed e.g. by
> rec.message() = "Hello world!";
Yes, that's the message I was talking about. It is not an attribute
value for the outlined reasons.
> I've asked before if binary logging is considered within the scope of
> the library. if it turns out that it's not, I can stop reviewing it from
> this angle at any time.
Yes, it has been considered. It is possible to create a binary sink that
will serialize the attribute values and the message.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk