Subject: Re: [boost] [log] Boost.Log Formal Review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-17 15:29:04
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.