John Torjo wrote:
Daniel Frey wrote:
John Torjo wrote:
Daniel Frey wrote:
John Torjo wrote:
I've just updated the Boost Log Library: http://torjo.com/code/logging-v132.zip
It's good to see progress on logging and what I've seen so far looks promising. However...
BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something....";
...while I like the feeling of the stream approach from a user's perspective, there is one (IMHO important) feature that can not be implemented with it: Exception guards.
When there's a will, there's a way ;)
You do raise a very valid point -- about exceptions. I will add exception guards.
Looking at the latest version (-v133.zip), I neither found them in the code nor on the ToDo-list. And I can't imagine how you could be able to add them with the current design, but I might be missing something. Care to share your ideas how to do it even in case the technique probably won't make it into your library? I'm just curious to learn a new trick :))
As far as I can think right now, it should be something like :
if ( std::uncaught_exception()) return; // there's an exception
try { do_logging; } catch(...) { // an exception occured while logging // eventually could call an on_logging_exception handler // then, eat this exception (it occured while logging) }
That's not the point. The point is, how you can catch exceptions with your stream-like interface: std::string f() { throw 42; } BOOST_LOG(app) << "Huhu!" << f(); This should IMHO write something like Expression " << "Huhu!" << f();" can't be logged to the log-stream as outlined in my message some levels up in this thread.
Another point: IIRC, some month ago we talked about the logging library in an earlier version. I proposed to allow
if( app ) { ... }
instead of
if( BOOST_IS_LOG_ENABLED(app) ) { ... }
and you agreed it makes sense. AFAIR it appeared to be very easy, but the library evolved since then. Is it still possible in the current library?
It is, with one small elaboration. At this time, when doing BOOST_DEFINE_LOG(app), BOOST_DECLARE_LOG(app), internally, I append something like "_log" to the actual log name, as to not collide with any other possible uses of 'app' as a variable or whatever.
Thus, you could say:
// note: it even works now if ( app_log() ) { ... }
Why do you add _log anyway? Now you still have potential clashes with a variable app_log, but it's no longer as direct and transparent as simply saying that BOOST_DEFINE_LOG(X) reserves X. I'd definitly prefer the latter, just my 2c. And in case you really want to avoid clashes and you don't expose the name to the user, you might consider prepending something like BOOST_LOG_ to the names. Regards, Daniel