Re: [boost] [log] Release candidate 1

Subject: Re: [boost] [log] Release candidate 1
From: Stefan Strasser (strasser_at_[hidden])
Date: 2013-03-11 04:04:10

Am 11.03.2013 04:17, schrieb Andrey Semashev:
> On Monday 11 March 2013 02:24:44 Darren Garvey wrote:
>> Hi Andrey,
>>
>> I'm glad you've added the trivial logger. As big as that warning is in the
>> documentation, it would be more reassuring to see that this logger supports
>> lazy evaluation of the logging expression if the example demonstrated it.
>> eg.
>>
>> // Note: some_very_expensive_operation() won't be called unless debug
>> logging is enabled.
>> BOOST_LOG_TRIVIAL(debug) << "A debug severity message" <<
>> some_very_expensive_operation();
>
> Regardless of the logger you use, that's the case; the streaming expression
> won't be evaluated if the filter does not pass the record. It's mentioned in
> the docs in several places.

http://boost-log.sourceforge.net/libs/log/doc/html/log/rationale/why_not_lazy_streaming.html

I came away from this thinking that the library doesn't support 
conditional evaluation at all. Maybe you can clarify that you chose to 
implement conditional evaluation not by lazy streaming but in another way.

What I find a little strange interface-wise is 
logging::core::get()->set_filter(...)

I haven't followed the review process so maybe there is good reason for 
this.
How many cores are there? if it's a singleton, as the documentation of 
get() says, why does it return a pointer? can it be a nullptr?

and isn't whether the core is a singleton object or not an 
implementation detail anyway?
then it could be a static function logging::core::set_filter(...)?

The documentation is clear and to concise for someone only interested in 
trivial logging.

Stefan