Re: [boost] Debug/Stream Libraries?

From: Roland Weiss (weissr_at_[hidden])
Date: 2001-11-26 06:17:35

> Personally I don't like using iostreams for debug logging. I
> experimented with this with CodeWarrior Pro 6 (I think it was) and
> got insane amounts of bloat. Every file that used logging wound up
> 100K or more larger. Of course the linker will strip all this crap
> out, but it make's it harder to get a first approximation of where
> the bloat is and all that duplicate code has got to slow down both
> compiling and linking.

Yes, this is a valid concern. IOstreams really are heavyweight. But
I think that it depends on your kind of logging if you could tolerate
this overhead. I use my logging class also to log the progress of the 
application, not only for debugging purposes.

> >Each stream can be bound to a different
> >ostream, and each stream has its own threshold (to
> >prioritize logging messages).
>
> I do this a bit differently. When clients want to log something they
> can specify a logging category (eg LOG("Sockets", "Sent ", bytes, "
> bytes to ", address, ".\n")). When LOG is called it assembles the
> string (using overloaded ToStr functions) and passes the string and
> the category to the logger.  The logger checks to see if the category
> is enabled and if it is hands the string off to zero or more log
> sinks. Log sinks can write to a file, standout output, or where ever.

I like the idea of log sinks, enabling the user to write to several
output streams simultaneously.

> The nice thing about this is that it's simple to use, messages are
> filtered with a meaningful name instead of a number, there's no bloat
> yet it's still type safe and extensible, and it can be easily
> customized with different sinks.

For every application I create one instance of the logging template and
provide constants to access different categories and thresholds, so
producing a logging message looks like this:

      g_log(lc_debug, lt_medium)
        << "Value node has "
        << dom::count_children_of_type(element, DOM_Node::ELEMENT_NODE)
        << " children of type ELEMENT_NODE.\n";

This gives as much information as a the string, I guess: The logging goes
to the lc_debug category, the threshold is lt_medium. Another question is
if you want to add categories at runtime.

There are a lot of design decisions to consider for logging, tracing etc.
I would be interested in talking about such a set of class templates
(and marcos?), but currently do not have the time as I write down my
thesis...

Roland