On Fri, 22 Oct 2004 17:16:14 -0400 (EDT), Rob Stewart wrote
From: Chris Uzdavinis <chris@uzdavinis.com>
Rene Rivera <grafik.list@redshift-software.com> writes:
It's possible without macros for some compilers using careful template instaciations.
For example the very simple logger I wrote uses syntax like so (and yes I prefer printf formatting :-)...
log<RevisionLog>::trace( "RevisionControl::commit_; wait for ticket #%d",ticket);
Because the formatting is done by the trace call, and the trace call is empty (and inlined) when the log is disabled, no formatting takes place. Something similar can be done regardless of what the formatting object is by having a specialization that does nothing.
That does not eliminiate any overhead that may exist due to evaluating the function arguments prior to making the call, nor any potential side effects of those expressions.
Personally, having debugging log statements completely disappear from the source code in a release build is more comforting, even if it involves a macro.
There are also plenty of times in which you want logging available in release builds but you want minimal overhead when it is disabled. A macro helps there, too, by moving the evaluation of the argument list into the body of a conditional statement.
Well, personally, I'd really like to try and go macro-less on the logging approach. I don't like macros because: 1) The logging code will be in the release build anyway (for all industrial apps I've seen this is the case). 2) Macro systems tend to be fragile -- pass it bad type (eg:string instead of char*) and it might crash your app. In this day and age the compiler should detect these errors... 3) I hate having to read macro code and then 'expand it mentally' -- I'm getting too dang old for it. Because of #1 I'd actually be fine if all the macro did was enable/disable so I it's use would effectively be optional. Jeff