From: Jeff Garland (jeff_at_[hidden])
Date: 2004-10-22 16:38:16
On Fri, 22 Oct 2004 17:16:14 -0400 (EDT), Rob Stewart wrote
> From: Chris Uzdavinis <chris_at_[hidden]>
> > Rene Rivera <grafik.list_at_[hidden]> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk