On 2007-04-04, David Abrahams <dave@boost-consulting.com> 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@arlut.utexas.edu