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