Boost logo

Boost :

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.


-----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]

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at