Re: [boost] Proposal: Logging library

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