Boost logo

Boost :

From: Ernie Makris (ernie_makris_at_[hidden])
Date: 2002-04-09 09:59:39

Hi Jeff,

My comments are inline.

>From: "Jeff Garland" <jeff_at_[hidden]>
>Reply-To: boost_at_[hidden]
>To: <boost_at_[hidden]>
>Subject: RE: [boost] null ostream (was Logging library)
>Date: Tue, 9 Apr 2002 07:28:00 -0700
> > 9 Apr 2002 07:32:09 +0400 Jeff Garland wrote:
> > >
> > >-- a null log stream class that has all empty functions. This can be
>Eugene Karpachov wrote:
> > How does "null _log_ stream" differ from just "null stream"? AFAIR we
> > already have null stream buffer in boost, hence we have null stream.
>The problem is that the null stream buffer still has the overhead of the
>ostream class calling into
>the stream buffer to do nothing. That is, the logging will still have some
>performance impact on
>production code. My goal was to have zero impact.

One way I've been toying with zero impact, is the following:

template <bool cond>
struct DebugSys {
  enum { R = 0 };

template <>
struct DebugSys<true> {
  enum { R = 1 };

if( DebugSys<DBUGFLAG>::R )
  logger << log_debug << "Starting server....";

most, if not all compilers remove the unreachable code when R evaluates to
0, when DBUGFLAG = false. It's a little bit ugly, but it forgoes macros, and
your program has a single source source set. Rather than two versions of the
set. It makes debugging easier. The compiler decides when to remove the code
I have tested this on Metrowerks for Mac OSX.1, I generated the asm and took
a look at it, both debug and release builds eliminated the code generation
for the logging call and the if statement, and it was left in when
DebugSys<true> is the case.

One of the drawbacks to this technique is, you cannot switch , dynamically,
logging on and off when log statements are written this way. The code no
longer exists.
>A traditional solution to what I was after would be to use the ugly macros
>throughout the code:
>void f() {
> //some code
> #ifdef DEBUG
> logger << "log data" << endl;
> #endif
>In a large program you could wind up with thousands of these macros
>polluting the code. So with
>null stream you have one #ifdef to set the stream to either an ostream or
>null stream. The rest of
>the code is written without conditional logic:
>void f() {
> //some code
> logger << "log data" << endl; // optimized out by the compiler in
>release builds
>So null ostream and null stream buffer serve different purposes. null
>stream buffer can be switched
>at runtime while null ostream is switched at compile time.
>Unsubscribe & other changes:

Get your FREE download of MSN Explorer at

Boost list run by bdawes at, gregod at, cpdaniel at, john at