Re: [boost] A meta-proposal for logging

From: Austin Bingham (abingham_at_[hidden])
Date: 2007-04-05 09:38:14

On 2007-04-04, David Abrahams <dave_at_[hidden]> wrote:
>> IMHO, we're not talking about including it into boost, but we're
>> looking for a proper design solutions and frequently requested useful
>> features, aren't we?
>
> Yes, that's right.  If the design is really "perfect," we can
> certainly do our own implementation if need be.

The pantheios system certainly has some interesting aspects as well as
some shortcomings, all of which are worth considering. Let me also 
start by saying that the pantheios documentation is lacking and I
don't have time to read the code in depth; if I'm way off target on
what I say here, someone please correct me!

Pantheios goes to some lengths to ensure minimal copying and memory 
usage, and this is certainly an area that people will be interested 
in for any logging library. Likewise, it has a sort of half-lazy 
evaluation scheme for logging arguments. That is, an object won't be 
converted to a string for logging unless logging is enabled. However,
a function producing that object (if any) will always be called when
the logging statement is made. 

Pantheios uses a matrix of overloaded functions (as opposed to, say,
streaming operators) to implement the logging statements. This
matrix is dimensioned on log severity and the number of arguments to
the statement. This overloading-on-argument-count strategy is well 
understood and used throughout boost. The notion of hardcoding
severity levels into the function name is, IMO, suboptimal and
likely to generate a lot of friction. It presupposes not only the 
type of attributes one might want for a log message, but it 
also presupposes the legal values of that type. It's likely that
the design described here was directed to a large degree by
the goal of having a C API along with the C++. 

Pantheios has a system for routing log messages to different sinks. 
This is implemented as the interplay between what they call the
front-end and back-end layers, and it appears to be an extensible
system to some degree. That is, they provide the ability to send
output to different destinations (debug windows, files, etc.), and
other destinations can be coded to work with the API.

Pantheios allows the logging of arbitrary type through the use of
what they call shims. A shim appears to be nothing more than a
facade pattern using overloaded function resolution to adapt types
to a particular API. They seem to put a lot of stock in the 
technique, though I tend to think that it might be unwieldy in
practice.

Anyhow, this is really just the briefest of reviews of pantheios.
Others should probably check it out as well, but I think that it's
pretty far off the mark of what the general boost population will
be looking for. We might get some good ideas from it, but it needs
some serious extending. Of course, some significantly better
documentation would be a good step in the right direction.

--
Austin Bingham
Signal & Information Sciences Laboratory
Applied Research Laboratories, University of Texas at Austin
10000 Burnet Rd., Austin, TX 78758
email:  abingham_at_[hidden]