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.