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