Re: [boost] [log] Release candidate 1

Subject: Re: [boost] [log] Release candidate 1
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-03-11 05:13:15

On Mon, Mar 11, 2013 at 12:04 PM, Stefan Strasser
<strasser_at_[hidden]> wrote:
>
> 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.

Well, the page you referred to explains it. Building template
expression for a streaming expression is not cheap, both compile time
and run time. It also requires quite an amount of scaffolding on
user's side to make his function calls lazy as well. Checking the
filter condition and then executing a regular streaming expression
depending on the condition result is more straightforward and
efficient.

> 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 core is a singleton, yes. The pointer is returned to allow to lock
the core from destruction on program termination. The core won't be
destroyed while there still are loggers.

Not that the library works ok on program termination, but the existing
problems are not related to the premature core destruction, and this
pointer technique lays the foundation for further improvements in this
area.