From: John Torjo (john.lists_at_[hidden])
Date: 2004-10-29 13:35:39
> 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.)
(As a side-note, I assume you've seen the ts_appender(), which does the
*appending* in a different thread)
That's an interesting idea.
One problem that I see with the above taking place in another thread is
that you don't know when it'll happen. This does not play well with:
- pre-pending time
- pre-pending thread ID
And probably some other modifiers I'll write or other people will.
As another side-note, if you really want this, you can write an appender
which will modify the original string and then write it to some
> - I miss priority/severity levels :-(
I don't like the idea of locking you into some fixed priority/security
You can always create your own "app.err" (error), "app.dbg" (debug),
"app.warn" logs, and log directly there (which you can then
enable/disable at any time)
> - 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).
From your point of view, you can still think of it that way.
The best way to better grasp this IMO is to take a look at the examples.
I would say that the coupling is as loose as possible ;)
Whenever you add an appender/modifier, you don't specify which log it
will be added to - you specify a logs_specification, where you can use
the * wildcard (same goes for enabling/disabling).
For example, to write all errors to cout, you'll say:
// assuming all error log(s) contain 'err' in their string name
To turn off debug logging, simply say:
// assuming your debug log(s) all contain "debug" in their string name
> - 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
This dependency is only if you use threads yourself.
The library needs to be thread-safe, and it would really see awkward to
reinvent the weel. Also, ts_appender() clearly needs it.
> - Tests?
> And a question:
> - Did you consider the possibility to integrate with syslog / NT event log?
Yes, in the future. Any help is welcome in this area.
-- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk