John Torjo wrote:
I've just updated the Boost Log Library: http://torjo.com/code/logging-v132.zip
* How much effort did you put into your evaluation? I've only read the documentation, not tried the library (i have given a quick try to a previous version, but that was long ago). * What is your evaluation of the potential usefulness of the library? A logging library is a must have, just like a multi-threading and a windowing library, but i am afraid that developing a one size fits all logging library is not much simpler than doing so for these other two. This library is already much better than most i have seen, but it is not useful for me without several changes. * What is your evaluation of the documentation? It is too brief. * What is your evaluation of the design/implementation? I would like to see three components: - the viewer application on John's page should be officially part of the library, with the option of running it as a separate application/running it as a thread in the application being developed - the current libary should be split into a logging primitives (building blocks) part - and into several "..._style_log.hpp" interfaces, supporting the different styles and bells & whistles and different default settings people ask for My main concern about logging is that it changes application behaviour: often there are bugs that only surface in release code because logging is slow and it introduces synchronizing, so logging should be as fast as possible, and locks should be avoided whenever possible. My style would be: Appenders: do not cache and do not use a dedicated writer thread, but each thread automagically creates it's own separate logfile. The files are kept open, flushed after each log entry, and the streams used for formatting the log entries are kept and reused. The log files are created in a system-dependent directory (e.g. %TEMP% on windoze), and the logs from the previous run are removed automagically. Modifiers: a global counter prefix, an indenter and a clock (secs elapsed since application start); and source file name, line number postfix. I do not want to declare and define and initialize logs, just include a header, and then write "LOG << ..."; i do not want to give names to logfiles, and i don't want runtime configurable logs and log levels and multiline log entries and calling functions that log from inside "LOG << ..." statements and i do not want to pay (with runtime and additional typing) for the features i do not use. I think a lot of the current library functionality can be moved into the viewer: it can merge the per-thread logfiles or scatter log entries based on a prefix (thus no need for named logs and different threads writing the same file), it can calculate entry times from the file creation date and clock stamp (to avoid time- consuming date formatting modifiers) etc. Also, having indentation in the logs allows the viewer to display the log contents as a tree-view making log browsing much simpler. * Do you think the library should be accepted as a Boost library? Not yet, i would rather put a link and a strong suggestion to use it on the boost webpage, and include it in boost only after it has been used in several projects. br, andras