Re: [boost] [log] Release candidate 1

Am 11.03.2013 13:48, schrieb Andrey Semashev:

On Mon, Mar 11, 2013 at 4:35 PM, Stefan Strasser 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.