-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Brinkman Sent: Tuesday, February 12, 2008 6:49 PM To: boost@lists.boost.org Subject: Re: [boost] [logging] Review of proposed logging library
With respect, I'm not sure there is *always* a better way than macros. For some applications macros provide a unique level of flexibility and efficiency. I'm the last person to advocate them, but when I constructed a logging library for our real-time scientific application, I was somewhat surprised to eventually figure out that logging macros *did* provide
the
best solution. So let's not discount John's effort on the grounds of anti-macro dogma alone, I'm sure we can find other problems ;).
I'm not discounting his efforts because of macros. What I am doing is pointing that they should be de-emphaisized and are not forced on me. If I dont care about the compile-time optimizations that a macro may provide, I should'nt be forced to use them.
Macros may provide some flexibility for some users, but others wont care about them and dont want to have to deal with them.
The typicaly use-case of the pubic interface of a c++ logging library should not include macros. They should only be offered as optional optimizations.
One of the most difficult aspects of writing a logging library is not making users' pay for what they don't log. I've noticed that with many logging libraries the inclusion of logging code incurs a run-time penalty of at least one "if" clause per log statement even if we know at compile time that some or all logging is not required. This is a big deal if one wants to liberally sprinkle logging throughout the application. For me, a primary requirement of the logging library is that it is efficient. If that can be done in C++, presumably using templates and compile time tricks to get rid of no-ops, then I'm all for it. I'm guess I'm just not smart enough to figure out how to do that, maybe John is! Efficiency first, features second.