Re: [boost] Simple Logging lib?

From: Andras Erdei (ccg_at_[hidden])
Date: 2002-07-12 03:13:54

On 11 Jul 2002 16:20:41 -0400, nbecker_at_[hidden] (Neal D. Becker) wrote:

>I know there was some discussion about logging, but I don't know if
>anything came of it.  I just want something simple, and I wonder if
>anyone has a suggestion.
>
>I want to be able to generate test vectors from my code by defining an
>appropriate preprocessor symbol, without seriously uglifying my code.
>The test vector generation would not be used in production code, and
>would output internal states not normally visible.

I can send you the current version of my logging lib, 
but right now it's:

- windoze only
- multithread-only (overhead if you are writing a single-threaded appl)
- non-boostified
- the implementation is experimental and quite ugly
- it can increase the startup time even for medium-sized
  apps significantly, as it uses the M$ ImageHlp stuff to
  find out function names (VC++ does not support __func__)

OTOH it's been already used in two projects, so it works.

>I'm thinking something like:
>
>DEBUG (TEST, STREAM, EXPRESSION)
>
>where TEST is a #defined symbol, STREAM is an ostream, and expression
>is I'm not sure what (I don't think cpp can actually do a general
>expression here).

It has a two-level interface; the upper (macro) level
does not resemble your request, basically it looks like:

  REPORT << "This is line # " << line << " in the log" ;

but it should be easy to replace the macros with your own,
using the (non-macro) lower-level interface.

The library supports logging into files and into a tree-view
(currently it does not do much -- you can search in it).

There is a FUNCTION/MEMBER macro which logs the name of
the function it's invoked from and changes the indentation
(changing it back at the end of the scope), an BLOCK/MBLOCK
macro for doing the same but with a text supplied by the
user instead of the function name (for inner blocks), a DUMP()
macro, and a TRACE() macro for inserting debug-only code.

In theory it has zero overhead in production code, but i
haven't verified that. (Production code still uses a few
no-op inline fns from the headers.)

br,
andras