On Mon, Mar 11, 2013 at 12:04 PM, Stefan Strasser
http://boost-log.sourceforge.net/libs/log/doc/html/log/rationale/why_not_laz...
I came away from this thinking that the library doesn't support conditional evaluation at all. Maybe you can clarify that you chose to implement conditional evaluation not by lazy streaming but in another way.
Well, the page you referred to explains it. Building template expression for a streaming expression is not cheap, both compile time and run time. It also requires quite an amount of scaffolding on user's side to make his function calls lazy as well. Checking the filter condition and then executing a regular streaming expression depending on the condition result is more straightforward and efficient.
What I find a little strange interface-wise is logging::core::get()->set_filter(...)
I haven't followed the review process so maybe there is good reason for this. How many cores are there? if it's a singleton, as the documentation of get() says, why does it return a pointer? can it be a nullptr?
and isn't whether the core is a singleton object or not an implementation detail anyway? then it could be a static function logging::core::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. Not that the library works ok on program termination, but the existing problems are not related to the premature core destruction, and this pointer technique lays the foundation for further improvements in this area.