From: Terence Wilson (tez_at_[hidden])
Date: 2008-02-12 22:46:05
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> Behalf Of Tom Brinkman
> Sent: Tuesday, February 12, 2008 6:49 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [logging] Review of proposed logging library
> >> With respect, I'm not sure there is *always* a better way than macros.
> >> some applications macros provide a unique level of flexibility and
> >> efficiency. I'm the last person to advocate them, but when I
> >> logging library for our real-time scientific application, I was
> >> surprised to eventually figure out that logging macros *did* provide
> >> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk