|
Boost : |
From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-06 15:09:57
Hello Michael,
Friday, April 6, 2007, 1:16:58 AM, you wrote:
> On 4/5/07, Greer, Joe <jgreer_at_[hidden]> wrote:
>> If we aren't going to live with that, then I think we need two filtering
>> points, because I, for one, don't want to pay the cost of formatting
>> numbers etc just to throw the message away because I'm not viewing that
>> message today.
> Why can't we format on-demand?
Hmm... I don't quite understand what do you mean by "on-demand". Could
you explain?
I see it something like that:
BOOST_LOG(logger) << "The message text";
This would essentially expand to something like:
if (logger.will_write_message())
logger.strm() << "The message text";
Here will_write_message would act as follows:
1. Construct the complete attribute set from the logger's, thread's
and global attribute sets.
2. Check the complete attribute set against the global filters. If it
does not pass, the record is discarded not even getting to any sinks,
and will_write_message returns false. No formatting takes place.
3. If the global filters pass the record, it is then tested similarly
against sinks' filters. The logging lib may remember which sinks
reported they will accept the record in order to avoid checking the
filters second time on the actual output. If there is at least one
sink that will accept the message, will_write_message returns true.
Otherwise it returns false.
4. If will_write_message returned true we then format the message and
put it directly to the sinks that will accept it.
Is this what you mean "on-demand" or do you see it differently?
-- Best regards, Andrey mailto:andysem_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk