I disagree. Like most things STL it should be independent of a stream back end. And ideally independent of a formatting front end. It should only be a tagging, filtering, and multiplexing interface.
internally, I use std::stringstream
* Thread-safe (e.g. two threads can't have their output intermixed in the output file/stream/whatever like they would with simple ostream<< operators)
Yes, but only if needed. It might not be appropriate depending on the front end or back end. For example you might be dumping the "output" to a database which would create individual debug records. No need for thread safety at the log level in that case.
indeed! that's what my lib does. You can choose to have a thread-safe writer, but only if you wish.
* Multiple possible output media (files, sockets, syslog, Windows event log, etc)
Multiplexing.
yup, we have that ;)
* Multiple named channels each with configurable "threshold" (e.g. error, warning, debug, etc)
And configurable, so that you can program what each one does on both the front end and to which back end they go to.
yup, we have that.
* Messages which won't be logged shouldn't even go through the formatting step. I'm pretty sure this cannot be done in a single call w/o macros though. For example:
BOOST_LOG (boost::log::debug, "This is a debug message: " << some_expensive_to_stream_class);
Which would expand to something like:
if (boost::log::is_enabled_for (boost::log::debug)) { ostringstream __os; os << "This is a debug message: " << some_expensive_to_stream_class; boost::log::force_write (boost::log::debug, os.str ()); }
yup, we have that.
It's possible without macros for some compilers using careful template instaciations.
In my case, there's one macro: BOOST_LOG. 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.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html