RE: [boost] Proposal: Logging library

From: Terence Wilson (tez_at_[hidden])
Date: 2002-04-09 07:18:41

That's how I designed mine- 2 variables

1) Level
2) ID

The basic idea was to separate things out into 2 classes

1) CLog - the singleton that receives and distributes all messages of
pure base type CLogMsg
2) CLogListener - a base class for classes wishing to "listen" to
CLogMsg derived msgs.

I have listener classes such as

CLogListenerToStream, CLogListenerToXML etc. And the system can handle
everything from plain old strings to XML which can be parsed and logged
to a SQL database from within the framework.

Since some log messages may be relatively expensive to prepare, before
sending a msg code can test for the existence of listeners.

For what it's worth it does the job very well. It's certainly possible
to write a generic, efficient logging library. If someone with my
limited C++ talent can do it reasonably well, then I'm sure some of the
virtuosos on this list could contribute something of C++ standard
quality. And as it's been said, we need to stop reinventing this wheel.

Terence

-----Original Message-----
From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]
On Behalf Of Markus Schöpflin
Sent: Tuesday, April 09, 2002 3:31 AM
To: boost_at_[hidden]
Subject: Re: [boost] Proposal: Logging library

Andras Erdei wrote:
> 
> 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.

I agree with your classification of type and source but I think that
support for predefined levels is a must.

> 
> 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.)

Interesting. How do you generate the log messages? A simple log("WARNING
TCPIP whatever")? 

> 
> 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 '?'/'.').

Don't you think there is still too much of a speed penalty for using a
pattern matching algorithm? Especially if you think about multiple
sinks, and each sink using a different setting of filters.

[snip rest of message]

Markus
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost