Re: [boost] [log] Boost.Log Formal Review

Subject: Re: [boost] [log] Boost.Log Formal Review
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-17 16:04:10

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, March 17, 2010 8:29 PM
Subject: Re: [boost] [log] Boost.Log Formal Review

> 
> On 03/17/2010 03:52 AM, sam.gundry_at_[hidden] wrote:
>> (This is my first Boost library review so take it easy...)
>>
>>
>> For example, (a minor one, I know) but how do you
>> specify keywords via a settings file.
> 
> What keywords do you mean?
> 
>> I've found __LINE__ and __FILE__ missing as attributes. Andrey
>> advised these are part of named_scope but the formatting is currently
>> missing. Ideally - and I don't know if this is technically possible
>> but - I would prefer these as just another attribute. Instead of
>> requiring a BOOST_LOG_FUNCTION() call when you want to use them, you
>> should be able to specify it as per usual, something a long the lines
>> of:
>>
>> And then BOOST_LOG_SEV(...)<<  " a message" has the file and line
>> attribute values already. Note, no need for BOOST_LOG_FUNCTION.
> 
> Ah, I must have misunderstood you the first time. BOOST_LOG_FUNCTION 
> saves the coordinates of the _scope_, but you need the coordinated of 
> each log record. I see. Right now the simplest way to achieve it is to 
> add them to your custom logging macro:
> 
>   #define LOG(lg, sev)\
>     BOOST_LOG_SEV(lg, sev) << __FILE__ << ":" << __LINE__ << " "
> 
> A more graceful solution would involve adding those parameters as the 
> logger-specific attributes and, perhaps, developing a logger feature to 
> simplify their setting from the macro. I may develop such a feature and 
> include it into the library.
> 
>> With respect to compiling out the log messages: it would be desirable
>> for security, code protection and/or performance if the ability to
>> specify certain log records to be stripped out of the source code.
>>
>> A hack such as follows - which is obviously extremely inflexible -
>> allows the users to define LOG_NTRACE to compile out all trace
>> messages:
> 
>> #if defined (LOG_NTRACE)
>> #define LOG_TRACE(logger, stream) (void(0)) ;
>> #else
>> #define LOG_TRACE(logger, stream) BOOST_LOG_SEV(logger, trace)<< stream;
>> #endif
>>
>> Something a lot smarter and flexible built into the library is
>> desirable. Say, templated on your custom severity levels (or, indeed,
>> any arbitrary attribute) and generating disable/enable macros.
> 
> I think, your simplistic solution is the most efficient, actually. It 
> could be implemented by returning a null stream from the logging macro, 
> but there's no guarantee that the logging code will be wiped out by the 
> compiler.

maybe

#if defined (LOG_NTRACE)
#define LOG_TRACE(logger, stream) if (true); else logger
#else
#define LOG_TRACE(logger, stream) BOOST_LOG_SEV(logger, trace)<< stream;
#endif

I would like all the BOOST_LOG logger macros works this way.

Best,
Vicente