Re: [boost] Boost Logging library - first draft

From: Gareth Buxton (gareth.buxton_at_[hidden])
Date: 2007-03-31 19:43:21

Hi Jean Daniel

I also have been working on a logger and have been considering
proposing it for inclusion in boost.

I feel that a logger must be both simple and a natural extension
of the standard stream libraries. Essentially everything should
be a stream. A logger then is merely a facilitator for managing
streams of messages generated by a piece of software.

So if you want to send some of your logging output to a file you
might attach a std::fstream to the logger. If you want to sent your
output over a network you might attack a socket_stream to the logger.

So basically the logger manages the aggregation of various streams
of information.

In addition to this the logger must enable a certain amount of
control over these aggregate streams. Traditionally this is managed
by masking off one or more streams when their output is not desired.

The other form of control the logger would need to exert over the
data itself would be formatting information. Each logging event will
capture a definite amount of data at a given point in program execution.

This data would typically be time, date, message etc. The logger
should not format this data itself as that would be too restrictive on
the desired output. Rather the logger should be able to accept a
formatting object to do this job appropriately to the given task.

For instance I might want one output stream going onto disk performing
the absolute minimum of formatting for maximum performance.

In addition to this I might want to be able to turn on a second output
stream which writes much more user friendly messages to the terminal.
The formatting of this stream could be much embellished as performance
would not be critical.

This would mean that I should be able to pass a formatting object to the
logger for that stream that produces nicer results. For instance it could
introduce terminal control codes into the collected data to give spiffing
color output.

So to put this into typical code one might have:

#include <boost/logger/log.hpp>
#include <iostream>
#include <fstream>

using namespace std;
using namespace boost;

fstream disk_stream("disk.log");

logger& log = logger::get_logger(STANDARD_LOGGER);

int main(int argc, char* args[])
{
    log.attach_ostream("term", std::cout);   // to terminal
    log.attach_ostream("disk", disk_stream); // to disk

    log.set_log_form("term", LOG_FORM_XTERM); // color formatted
    log.set_log_form("disk", LOG_FORM_RAW);   // machine readable

    log << "Begin logging" << endl;

    for(int i = 0; i < 10; ++i)
    {
        log << "Message number " << i << endl;
    }
}

So basically the logger itself remains simple, all it does
is manage a collection of std::ostream derived objects.

Externally defined formatting objects are employed to manage
the actual presentation.

I personally feel that macros should be avoided as much
as possible. One argument for using macros is the ability
to conditionally include or exclude the logging code at
compile time.

However this view is usually a product of 'developer centric'
thinking and misses the much more important 'user centric'
aspects of logging. The fact is that there are an awful lot
of reasons to add logging information to a piece of software
other than debugging. It is often desirable to be able to
monitor the ongoing state of any medium to large sized application
so this activity is not solely for the benefit of the developer.

On top of this, the number of places in a piece of software
where performance is critical is often quite low. For really
critical sections of code then of course a compile time defined
macro could be appropriate. However I feel that in the many
cases logging should be considered an integral part of the
software being developed and so to be available in the
production hardened release.

The current version of my logger is hosted on sourceforge.net
at http://sourceforge.net/projects/logplusplus/

Right now it is undergoing some major revision to separate out
what really is core logger activity and what is 'optional extras'.
When that is complete I will likely place it in the sandbox for
interested people to assess.

Jean, I will be looking over your contribution soon to see what
common ground our loggers share and if there might be a possibility
of some 'cross pollination' of ideas.
 
Regards,
 
-Galik

JD wrote:
> Hello,
>
>    So here is the question:
>     "Is there any interest in a logging library for boost?"
>
>    John Torjo did not answer my mail, beside I looked at pantheios. it
> seems a little bit complex... My idea is that a logging library should
> be _simple_ to use.
>