Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
On 03/08/2010 03:00 PM, strasser@uni-bremen.de 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. the reason I asked this question is because I think log records need to have (type) identity. especially for (but not limited to) reading back log records, as was discussed when the review was announced.
- 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 application.
- 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. my focus here was again WAL. WAL records consist entirely of attributes that are dumped in binary form. I presume attributes are now stored in a std::map<std::string,Attribute> or similar. this is not an acceptable performance overhead for WAL.
- 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.
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!"; 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. Regards,