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
> 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
> #if defined (LOG_NTRACE)
> #define LOG_TRACE(logger, stream) (void(0)) ;
> #define LOG_TRACE(logger, stream) BOOST_LOG_SEV(logger, trace)<< stream;
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk