Re: [boost] [log] Release candidate 1

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

On Mon, Mar 11, 2013 at 4:35 PM, Stefan Strasser <strasser_at_[hidden]> wrote:
> Am 11.03.2013 13:27, schrieb Stefan Strasser:
>
>> Am 11.03.2013 12:51, schrieb Andrey Semashev:
>>>>
>>>> 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.
>>
>>
>>
>> I'm not suggesting any changes to the internals, only to the interface.
>> Maybe the following code makes it a little clearer:
>
> was your point that the destructor A::~A in my code can't use the static
> functions? that's correct, but it can't use the current "static core::get()"
> either.

Exactly. Loggers hold the pointer to the core and use it to emit log
records. If you cache a logger as a member in your A, you will not
have to call core::get() in ~A. But you will have to call some core
methods (through the logger) to write logs in ~A.

> log_during_termination can provide an interface for this corner
> case.

You mean operate on the core during the normal application lifetime
and on log_during_termination during termination? This seems
unnecessarily complicated and limiting. Your A class will only be able
to be used as a global object.