|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2004-10-25 13:41:31
From: "Jeff Garland" <jeff_at_[hidden]>
> On Fri, 22 Oct 2004 17:16:14 -0400 (EDT), Rob Stewart wrote
> > >
> > 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).
Some logging is debug only and really shouldn't be in the release
build. If the mechanism makes the overhead nothing more than a
Boolean test, without side effect argument evaluation, etc., you
could leave it in. Even then, each of those conditionals might
trigger a bad guess by early stages of a process pipeline, so it
might have deleterious effects on performance.
> 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...
If the macro does very little, such as produce a conditional
followed by one line of code, there's not much room for this
problem. It is also easy to see the definition of such a macro
to understand how it works.
> 3) I hate having to read macro code and then 'expand it mentally' -- I'm
> getting too dang old for it.
If the macro is simple, there should be no problem, even for an
old many like you. ;-)
> 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.
It may be that the best approach is one that exposes two
interfaces. One involves a macro that provides the smallest
runtime overhead. The other might involve one or two C++
functions or types.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk