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

From: Brian Hawkins (bmhmaillist_at_[hidden])
Date: 2002-04-10 01:50:22

Hello again,

I recently posted a response to the logging library thread that I would be
happy to contribute the framework I have been using for logging.  I believe
it may provide a reasonable solution to the problem of enabling/disabling
logs.  I can summarize part of that here and would be happy to provide more
of my source code once I have cleaned it up a little, let me know if there
is interest.

OK, so to summarize the part that is relevant to this thread.

A log class is available that supports:
        Conversion to boolean (true to enable, false to disable)
        operator<< for output (the class is policy based so the exact method is
configurable)

Now we provide a define:

#define LOG(type) (type) && (type)

and we can then use it like this:

LOG(some_type) << "Log message\n";

This reduces disabled logs to a test and a branch, and they can be optimized
out in release builds by making the log class conversion to boolean an
inlined return(false).

I have found no way to avoid the macro unfortunately, all other approaches
subvert the logical AND short-circuit that this approach relies on.

Let me know any thoughts.

Thanks,
Brian Hawkins

-----Original Message-----
From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]On
Behalf Of Jeff Garland
Sent: Tuesday, April 09, 2002 7:28 AM
To: boost_at_[hidden]
Subject: RE: [boost] null ostream (was Logging library)

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

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