From: "Jeff Garland" <jeff@crystalclearsoftware.com>
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;