From: Niko Demmel (niko.demmel_at_[hidden])
Date: 2007-04-07 16:17:31
On 06/04/2007 21:49, Andrey Semashev wrote:
>>> Well, there's no point to log an empty record. At least message text
>>> should be present in any record, don't you think so?
>> I don't think so. How about I define an new attribute for my logger
>> which is some object that I want to convert to text and format lazily?
> I don't see how is it different from message text. You just output
> your object to the logger stream and see it in the log.
If it comes down to something like this
logger.strm() << "The message text";
then forget I ever said anything. I had some other idea of how lazy
logging would work in my head, but now realized it won't work.
> I think, there will be no restriction on constructing attributes and
> storing them in STL-compatible containers. Although the library itself
> will use only those three listed above, so user will have to add his
> attributes to one of these if he actually wants to log them.
>>> But still, I am convinced that the message text should always be
>>> there. This fact in conjunction with its lazy construction, actually,
>>> makes it so special that it may be not an attribute at all.
>>> And as a side note, this will make it impossible to filter by the
>>> message text just because it won't be available at the time of
>>> filtering. Can we live with that?
>> I think we shouldn't. See above. Filtering by text should be possible to
>> implement, but IMO not be directly provided by the library.
> Hm. Let's put in this way. It may be possible but not though the
> regular filtering mechanism. A sink may actually decide wether to
> write the message to the output or not after the regular filtering was
> applied and formatting was made. This makes the difference between the
> message text and other attributes even greater.
> Otherwise I don't quite realize how to implement it in a user-friendly
> way. I wouldn't want to lambdify each logging record.
Ok, I now realize the difference between the attributes and the message
itself as you put it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk