controlled by runtime 'levels' so that each destination filters out what it 'stores'
Will do.
streams like a file should support rotation on size and/or date, with possible post rotation actions (e.g. compressing)
Latest version allows rotating logs.
the log processing might run under a separate thread so that the slow actions of logging can be decoupled from the main application. In real high performance situations this will probably be via some form of fixed size circular buffer per logging thread and may be allowed to drop messages on full condition (embeded style applications) other times buffer may be allowed to grow.
There's a ts_appender() with similar functionality.
date/time stamps switchable on/off
You can do this by adding or not adding a prefix_time() modifier.
potentially a 'source' indicator should also be logged e.g. thread id or alternatively an application provided identifier
Again this is possible by adding a custom modifier.
clasifications of errors/warnings/info/debug etc each with separate 'levels' should be possible. Whilst this is conceptually odd for 'error' it makes sense under debug or info. There clasifications should be user supplied to allow for domain specific messages to be routed to the correct destination
To do.
multiple threads should be able to log without affecting others, I see the core of the logging system as a gather and then scatter type operation, with a M-N relations ship broken down into a M-1 and 1-N with each relationship potentially having its own buffer/queue
Yup, the lib is thread-safe. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!