From: John Torjo (john.lists_at_[hidden])
Date: 2005-05-04 04:30:33
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
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
>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
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
>Modifiers: a global counter prefix, an indenter and a clock (secs
>elapsed since application start); and source file name, line number
>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
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.
-- 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk