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.
-----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.
AMDG Terence Wilson wrote:
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.
As a matter of fact, John's library uses an if statement, too. However, if the condition is known at compile time the compiler can optimize it away perfectly well. In Christ, Steven Watanabe
On Feb 13, 2008 4:57 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Terence Wilson wrote:
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.
As a matter of fact, John's library uses an if statement, too. However, if the condition is known at compile time the compiler can optimize it away perfectly well.
And even if the condition weren't known a compile time, IMHO the effect wouldn't be measurable anyways, except in the thightest loop of a program. An extremely predictable branch like that costs practically zero on modern architectures. -- gpd
on Tue Feb 12 2008, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:
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.
If the macro is doing something sufficiently interesting, you won't want to have to deal with the replacement. Some things just can't be captured with syntactic economy any other way. -- Dave Abrahams Boost Consulting http://boost-consulting.com
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.
If the macro is doing something sufficiently interesting, you won't want to have to deal with the replacement. Some things just can't be captured with syntactic economy any other way.
Thanks Dave! Anyway, in the next version, I'll certainly explain what each macro does (should have 2 macros at most) and how you can accomplish the same thing manually. Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right
participants (6)
-
David Abrahams -
Giovanni Piero Deretta -
John Torjo -
Steven Watanabe -
Terence Wilson -
Tom Brinkman