From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-10-29 08:50:18
"John Torjo" <john.lists_at_[hidden]> wrote in message news:41812C6E.10903_at_torjo.com...
> Dear boosters,
> Finally, have had some time to update the logging lib.
> Get it from: http://www.torjo.com/
> (of course, it comes packed with docs)
> Still to do:
> - docs: write about log managers
> - cyclic logs
> Looking forward to your feedback!
Disclaimer: I haven't used the library (yet), just read the documentation and peeked at the code. As I (as well as nearly everyone else in the world) have been using/implementing logging stuff, I'm very interested in a logging library. Having a logging library in boost would simplify dependency management for me personally, as boost is the single dependency that I add to the SCM system (almost without thinking) when starting out some new C++ development. As these comments come after a first read-through only, they're probably not very complete.
I feel a bit ambivalent about the library, on the one side:
- I like the syntax, e.g. BOOST_LOG(x) << "log a message". Really smooth to use, especially when adding ad-hoc logging.
- I also like the ability to use decorators (i.e. "modifiers") - prepend_time et al
- The option to manage logs using wildcards also looks really nice
- In general, looks really easy to use and setup.
- The usage of TSS in the thread-safe stuff is neat, great idea.
On the other side:
- Message formatting always takes place in the caller's context. In ~99% of the time I'd like the messages to be formatted and written to their destination in a low-priority (idle) background thread, that does not interfere with any other parts of my application. This holds true even when I don't use any threads in the application. The only time when I would not want do it this way is when the platform does not support threads. (I deliberately do not suggest any specific implementation here.)
- I miss priority/severity levels :-(
- I get the feeling that the logging entity always knows where the log messages are destined. I'd like (I think) a single logging "sink" where the messages can be sorted at the back-end ("appenders") to provide some looser coupling (read the comment at the bottom of this posting though).
- This opinion is probably not shared with others, but I'd prefer the library to be independent from the Boost Thread library. The dependency feels kind of the wrong way around.
And a question:
- Did you consider the possibility to integrate with syslog / NT event log?
Many of these points probably originate from me not really getting the feeling for the usage of the multiple, hierarchical logs. Would you (or someone else) take a shot at explaining what the differences/benefits are compared to using e.g. severities?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk