RE: [boost] null ostream (was Logging library)

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 
>used
>
>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 
altogether.
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.
>
>Jeff
>
>
>_______________________________________________
>Unsubscribe & other changes: 
>http://lists.boost.org/mailman/listinfo.cgi/boost

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.