Boost logo

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