Boost logo

Boost :

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


Am 11.03.2013 13:48, schrieb Andrey Semashev:
> 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.

okay, if the loggers don't use get() but hold a shared_ptr (and aren't
destructed yet themselves) the problem doesn't exist anyway. then the
non-static functions have to be public for the loggers to use.

I wasn't trying to get into a discussion about how logging during
termination is best implemented, all I'm saying is that such a corner
case like logging during termination should not force a regular user to
use a rather strange interface.

none of the internals, however they may be, have to change for that.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk