Re: [boost] [log] Release candidate 1

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

On Mon, Mar 11, 2013 at 2:22 PM, Stefan Strasser <strasser_at_[hidden]> wrote:
> Am 11.03.2013 10:13, schrieb Andrey Semashev:
>>>
>>> What I find a little strange interface-wise is
>>> logging::core::get()->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.
>
>
> then it's an implemention detail, I'd suggest making all the functions of
> logging::core static, or make logging::core a namespace.
> if you wanna add the feature you've mentioned later on, you could for
> example ask the user to construct and hold a core::log_during_termination
> object, which - again as an implementation detail - holds a shared_ptr to
> the internal core.

This won't work because every static function would have to obtain the
pointer to the core which may be invalidated because its global
destructor has been invoked already. The user (or the logger) must
preserve the pointer and call core methods on that particular pointer
instance. You cannot reliably obtain a new instance of the pointer to
the core during program termination.

I had the idea of making the core default constructible so that it
would contain the pointer to the core singleton internally. But that
seemed a counterintuitive design to me as noone expects a default
constructible object to be actually a singleton.