From: Terence Wilson (tez_at_[hidden])
Date: 2002-04-09 07:18:41
That's how I designed mine- 2 variables
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.
From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]
On Behalf Of Markus Schöpflin
Sent: Tuesday, April 09, 2002 3:31 AM
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
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
> 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]
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk