|
Boost : |
From: John Eddy (johneddy_at_[hidden])
Date: 2005-01-31 16:30:48
In response to a number of great suggestions and interesting examples, I
have made some more changes to the logging library that I would like to
make Boost-worthy. I still have some changes to make and am mulling
over the way I would like to go about making them. At last posting, I
had made a policy of the logging levels and they can now be user
specified with my levels being the default (Thanks to Jason Hise for the
suggestion).
Since then, I have separated the management of a log from the log
itself. the log itself is a very simple thing and implements whatever
means of storage, display, etc. that it wishes (inspired by the
suggestions and mantra example of Preston Elder). A couple examples I
have created so far are a simple_log which keeps a list of entries for
retrieval (by predicate for example), an ostream_log which immediately
writes entries to a supplied ostream, a file_log which immediately
writes entries into a file with a specified name. I have created these
as examples but I don't see any reason why implementations for just
about anything could not be created.
I have implemented a callback system for log entries. A boost::function
can be mapped to a logging level as a callback in case of an entry at
the specified level. For example, this allows a user to catch what they
consider to be a "fatal" error and act on it. (Thanks again to Preston
Elder for the suggestion).
I have implemented a means of converting from levels to string
representations of those levels. This must also be carried out by the
same policy class that defines the levels. It requires the
implementation of a single, simple method in the class accepting a level
and an ostream and writing the appropriate text into the ostream.
I have implemented a means of customizing the format by which entries
are written (Thanks to Preston Elder and Caleb Epstein for the
suggestion). Again, it requires a policy class. This class must have a
method that accepts an entry and writes it to a supplied stream. Of
course, there is a null version for use in the case where you want to
have specific logs do all the writing themselves. If you want to have
custom formats for the entries, the only possibilities at this point are
to log them all anonymously with a completely formatted message and use
the text only entry writer or to implement some sort of logic in your
logger/writer to distinquish the entries and format them accordingly. I
am considering an ostream style message writing functionality as well.
Something I plan to do but have not yet done is change from a char
specific implementation (Thanks to Preston Elder for the suggestion) to
one that's non-char specific.
The code in it's current state is available for simple download from
www.eng.buffalo.edu/~johneddy. It is not well Boost-ified yet but the
directory structure is in place and some example files are available.
Everything is implemented in header files at this point so no library
need be built. There was a question of thread safety. The library is
threadsafe if BOOST_LOGGING_THREADSAFE is defined. It currently depends
on date_time and if thread safe, the thread library.
Thanks for all your help,
John
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk