From: Andras Erdei (ccg_at_[hidden])
Date: 2002-04-09 05:02:05
On Mon, 08 Apr 2002 21:47:35 -0400, "Ernie Makris" <ernie_makris_at_[hidden]> wrote:
>I'd like to propose the design and development of a logging library
>to be included in boost.
That would be really nice (i suspect i'm not the only one who have
implemented one several times -- in fact i'm just working on one
right now).
>- Ability to log based on levels
> The log stream would support levels, and a default level. etc...
IMHO levels are the worst solution. Usually i want things like
"get all error messages, but get the warnings only from two modules".
There are two independent criteria for enabling/disabling a message:
the type and the source of the message. The other problem is that
everyone wants different levels, and uses the painfully agreed-on
levels differently.
What i'm contemplating right now is basing the filtering on pattern
matching. There is an "enable" filter -- a list of patterns, like
["^WARNING TCPIP *", "^WARNING INTERPRET *unknown*" , "^ERROR *" ];
a message not matching any of the patterns on the enable list is ignored.
Of course if you tend to be terse, you can use [ "^WT*" , "^WI*unknown*" ,
"^E*" ] or whatever you prefer instead, and start your messages with
a single letter indicating the "level" of the message.
There is also a "disable" filter -- again a list of patterns which
can be used to get rid of some of the messages making it through the
enable filter. (In theory a single regexp is sufficient but that
would be cumbersome.)
What i don't know is whether a full-regexp matching is preferable
(with all the speed consequences) or a simple wild-card matching
('*' and '?'/'.').
>- Some basic sink types (file, console, ring buffer...)
Also (optionally) having a separate diagnostic application,
and logging via tcp/ip.
>- Ability to turn logging on/off dynamically
And preferably from the user interface of the diagnostics
module instead/besides of controlling it from within the actual
application.
>- Parameterizeable thread safety. Don't penalize programs that do not need
> thread safe logs.
Yup.
>Is there any interest in such a library.
Definitely.
Another thing i found quite useful is (on M$ Windows)
using a tree-view for diplaying the diagnostic info.
Each thread has it's separate branch, and each marked
block (function etc.) creates a sub-branch. (The log
files only indicate nested blocks using indentation,
and that's much less comfortable.)
br,
andras