Re: [boost] Re: [Q]: What is the recommended logging facility for boost: log4cpp or ??

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
> formatted.

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;