Hi Andras, Many thanks for the pre-evaluation!
* What is your evaluation of the documentation?
It is too brief.
Yes, indeed, I do need to provide more examples, usage scenarios, etc.
* 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
No problem there ;) However, you should note that at this time, the viewer application is Windows-only.
- 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
This is an interesting idea. In the future, I want to ask people to provide me with different scenarios in which they use logging. This, based on how many such scenarios I find, could then end up into what you say.
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.
Locks are 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.
Ok, so we could say we have the first scenario ;)
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.
Yes, that's the reason I created the viewer. However, I made the logging library flexible (or at least I hope so :)), so users can tweak the lib to their needs.Logging can be so much more that writing to one file.
* 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.
Sure thing ;) Note that I have used in in a quite a few projects (more than 6, I think; from which 2 projects were quite large), and have received (private) feedback from other people who have successfully used it in their apps. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!