From: Rob Stewart (stewart_at_[hidden])
Date: 2004-10-26 11:42:25
From: Caleb Epstein <caleb.epstein_at_[hidden]>
> On Mon, 25 Oct 2004 14:41:31 -0400 (EDT), Rob Stewart <stewart_at_[hidden]> wrote:
> > 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.
> I find great utility in being able to leave debug-type logging
> statements in production code and enable them as-needed when the
> situation arises (e.g. through sending an extrnal signal or command to
> a process). This dictates that the "is_enabled" check be very
> inexpensive, and that when it fails the log message should not even be
Note that I said "some logging" is debug only. That is, it is
specifically not wanted in the release build. I did not mean to
imply that all "debug-type" logging should be compiled out. The
point is that there should be a choice.
Darren Cook's BOOST_LOG and BOOST_LOGD (though I'd name the
latter, BOOST_LOG_DEBUG) permits the library user to choose
whether to leave the logging in the release build or not.
> > > 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.
> This is how the code John submitted works. A logging call looks like:
> BOOST_LOG (log_name) << the << things << to << output;
Right. I was including John's version in that description, but
it applies more generally.
-- 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