The scenario we use is something akin to the following (using macros):
LOG(int level, string tag) << "whatever";
The logging (as a whole) can be enabled/disabled. When enabled, portions (according to the 'tag') as well as the level, can be selectively enabled.
Besides levels, the rest is already in the existing lib.
Levels and tags are automatically inserted into the stream (for post-filtering if desired).
We generally have different logs/streams for different types of logging: errors, warnings, developer messages, determinism checks:
ERROR_LOG(...) << ...; WARNING_LOG(...) << ...; etc.
Yup... Similar usage: BOOST_LOG(err), BOOST_LOG(warn), etc. Of course, you can create your own macros, if you wish: #define ERROR_LOG BOOST_LOG(err)
Which of course can be tied (at runtime) to the same stream or different streams.
Yup...
There's always the push for "speed", so a compile-time disabling (akin to NDEBUG for asserts) of certain streams is required.
Already done, as suggested by Darren Cook. 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!