Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-15 07:07:11


Hi John,

> I know a while ago there was some interest in a logging library...
> However ;), recently I discovered a very easy way to do logging....
> The idea is to have a function that takes a const std::string&
> parameter, and it will be called whenever a new message is logged...

Well, to implement extra-simple logging I always can do:

function<void (const std::string&)> error
    = cout << constant("error: ") << _1 << "\n";

function<void (const std::string&)> warning
    = cout << constant("warning: ") << _1 << "\n";

int main()
{
    warning("something's wrong here");
    error("nothing works");
    return 0;
}

The complexity, though, is in processing which happens after the message is
send to logger -- checking when message should be printed, adding
timestamps, writing to files/syslog, etc.

What would be really good is have the logging library be a set of components
linked with boost::function or boost::signal.

What I mean? Take a look at LogJ4:
http://logging.apache.org/log4j/docs/api/index.html

There's Appender, Filter, Layout and a big number of other classes which all
know about each other and the whole system looks complicated. With
boost::signals, the system can be structured as a number of small classes,
each of which has operator() and can emit a signal. The the processing will
work like this:

1. User gets hold of boost::logger and outputs something
2. logger emits signal which can be then connected to a number of consumer
3. First consumer might be 'filter' which determines if the message should
be output at all. If it should be output, it emits signal again, which
might be delivered further
4. 'filter' might be connected to 'formatter', which adds timestamp and
again emits the signal.
5. 'formatter' might be connected to 'stream_writer' which stores the
message to a file and does nothing more.

So, I think it's good to have boost::logger just call a function/signal.

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk