$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Niko Demmel (niko.demmel_at_[hidden])
Date: 2007-04-07 16:17:31
Hello Andrey
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
if (logger.will_write_message())
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.
>
Ok.
>
>>> 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.
Regards
Niko