On Friday 08 February 2013 07:53:32 Mats Taraldsvik wrote:
I take it that you are initializing the library while initializing a global logger the first time, is that right? If so, then you probably should move all library initialization code (including addition of sinks and attributes to the core) to an external function and protect it with call_once, once blocks or another similar mechanism. Then you will be able to invoke it multiple times for different global loggers without reinitializing the core.
Unfortunately, no. I'm implementing a new module called by a legacy interface, and don't know the number of instances of that interface present at a given time (probably, it will be limited to one, but in my test code at least, multiple instances exist). Each interface therefore has its own logger object, and the initialization of this object, along with the initialization of backends/sinks/core, happens at construction of the interface object.
Currently I'm calling remove_all_sinks, and this works well. Another approach, that you suggest, would be a static once_flag member for the interface, and call_once for the backends/sink/core initialization. The latter introduces some complexity, and the former is not ideal. I think I'll try to avoid the complexity if the remove_all_sinks approach does not cause any issues..
If you use remove_all_sinks and reinitialize sinks etc. while the other instance of your module is active, it is possible that you lose a few records in the output (they will be fed to the default sink). I think, this was the original issue you mentioned, right? The call_once approach solves this problem.
The code sample in the sinks description is not related to trivial logging, and actually the filter itself is not important in that example. For clarity, if the filter extracts an int, like in that example, it won't work with other types, so the example assumes that the logger is also using int for severity levels. You can see it in the complete code of the example.
If you could include exactly that paragraph in the docs, when you move from trivial::severity_level to int, that would make things clearer :)
Ok, I'll see if I can clarify the docs.
As a side note, I'm extremely satisfied with the library. Thanks for developing it! :)
Thank you for the kind words. :)