Re: [boost] [Review] Boost.Logging: formal review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-15 16:39:16

> 1. Enabled/disabled logger, logging macros and efficiency
>
> The logging macro BOOST_LOG should accept two arguments instead of one.
> The logger and the log message. The syntax
>
> (1) BOOST_LOG(some_log) << "my message " << foo() << bar();
>
> should be replaced with
>
> (2) BOOST_LOG(some_log,  "my message " << foo() << bar());
>
> and the macro being defined something like this
>
> (3) #define BOOST_LOG(logger, msg) \
> if(logger.isEnabled()) { /* code that logs msg */ ... }
>
> Thus, disabled loggers will never take longer than simple if-statement,
> as long as the isEnabled() method is fast, which IMO should take no
> longer than comparing booleans.

1. I think this is also the case in original interface.

> In the original solution (1) the method foo() will always be called,
> which is inefficient when the logger is disabled, in solution (2), foo()
> will never be called when the logger is disabled.

I think you are mistaken

> Further more, the macro could insert extra information such as __LINE__,
> __FILE__ etc.

This is also true for original interface.

All in all I prefer message not be inside brackets. It looks much more 
natural and I don't see any theoretical problens to get the same 
performance. But I also believe that macro shouldn't be a primary interface. 
So if you prefer message inside the breakets - it's your choice.

> 2. Filtering
>
> There has been some discussion about the ability of a library to be able
> to do more filtering than simple log levels, notably by Gennadiy
> Rozental.
>
> Gennadiy writes:
>> At the bare minimum it should support:
>>
>> entry level - levels set is ordered set of values indication
> importance of
>> information provided. Filtering is based on threshold. Examples:
> DEBUG, INFO, MAJOR
>
>> entry category - categories set is a set of unique values indicating
> kind of
>> information provided Filtering is based on masking.
>> Examples: ARGS, RETURN_VALUE, ERROR_LOG, DATA_FLOW, PROG_FLOW
>
>> entry keyword - keyword set is set of user defined keywords (most
> frequently strings)
>> identifying area of the program. Filtering is based on match of
> keywords.
>> Keywords usually are used to mark specific part of application.
>
> I agree that it is very important for a logging library to support this.
> However, I do not think that the solution is for the logging library to
> be aware of such special values. The library should be as simplistic as

My position that library should be configurable by any class satisfying 
Filter concept.
This particular filters could probably be supplied by the library as an 
example and as most widely useful.

> My proposed solution is to basically let loggers be somewhat entry
> (Gennadiy's definition above) unaware. Instead, let the developer be

I do not see how it's possible. IMO framework should employ some MPL magic 
and construct proper entry structure based on set of Filters passed as 
template policy parameters.

> entry aware. By that I mean that the developer should log messages that
> belong to a specific entry category/level to a specific logger. For

This is never be acceptable IMO. Even with 3 filters, each ahving 5 possible 
values you looking into 125 different loggers.

> example, if there is a need to log and filter a RETUN_VALUE category,
> then a specific logger, perhaphs named RETURN_VALUE_LOGGER (or
> whatever), and let the user send log messages to that logger. This could
> look something like this:
>
>  BOOST_LOG( RETURN_VALUE_LOGGER, "The return value is: " << value );
>
> This solution also means that you have a different logger for each
> level, level filtering perhaps being the most common filter. For
> example:
>
>  BOOST_LOG( debug, "some debug output " << a << foo() );
>  BOOST_LOG( error, "Error: " << e.what() );

What if I need to filter by RETURN_VALUE category and INFO level?

> where 'debug' and 'error' are loggers. Now, the drawback with this
> approach is that several loggers needs to be defined and configured, but
> as long as this is simple this should be ok. There should also be
> default definitions and configurations available from the library, which
> "sits" on top of the basic library framework.
>
> As for entry keywords (see above), I see two interpretations of
> Gennadiy's idea. (1) A log statement is marked with a keyword. For
> example:
>
>   BOOST_LOGX( logger, "user defined keyword", "my log msg " << value );

This is my interpretation. And I need keyword based filter to filter out 
entries that doesn't comply.

> Or (2), logging is filtered on what strings are contained in the log
> message. That is, log statements are written in the normal way by the
> programmer but is filtered by some mechanism where the log message is
> matched against certain keywords, like the grep command.

Wow. That's novelty. You propose first format the message. Do all this hard 
work and then start costly substring searching? No, I wouldn't go this 
direction.

Sorry. I don't have a time for the rest. But you should get my opinion from 
above.

Regards,

Gennadiy