|
Boost : |
From: Daniel Frey (d.frey_at_[hidden])
Date: 2005-05-22 03:08:29
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk