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]]
On
> 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.
> 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.