On 03/17/2010 03:52 AM, sam.gundry@gmail.com 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.