Boost logo

Boost :

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-08-08 00:27:12

Excuse the break in threading - gmane has lost/missed a lot of boost traffic.

Hi John,
I've only had a quick look at the latest version:

The m_destroyed hack needs to go - this should only be relevant for static (not
scoped) logs and the real issue is that you need to do thread-safe singletons -
ie. you need to use posix call_once or equivalent to contstruct the thing.
Destruction is a bit tricky - not doing it seems a reasonable option, though
stopping leak detectors from compaining would be nice.

The scoped log stuff doesn't seem to have been updated to support levels yet -
in fact I'm not sure if it currently works?

I think (fancy that - given the way it was in analog ;-)) that the named
appenders need to be managed - currently, you can create multiple appenders
with the same name, then when you delete by name you delete all appenders with
that name. I don't see the utility of that model, which when combined with the
wildcard matching is really fairly hard to use. For example, suppose I have an
appender that logs to some sort of display for "real time" tracing. First off,
I say:

manipulate_logs("error.*").add_appender(displaywrite, "display")

Then I notice an error about some component foo and decide to look at more
detail about foo:

manipulate_logs("*.foo").add_appender(displaywrite, "display")

Now I get anything logged to "" written to "display" twice.

I then say:


Because I want to concentrate on "foo" only. Now I find I don't get errors from
foo displayed, only other less critical messaages.

Then, foo goes out of scope (it's a scoped log), only to come back into scope
again. When it does, and it generates an error, I'm (not really) suprised to
see it sent to "display"....

As the purpose of named appenders is to facilitate runtime modification of the
appender set, surely the ability to make these modifications using *only* the
name is reasonable. The fact that add requires a function while del only needs
a name only highlights this.

Regardless of what the rules for combining appenders/modifiers/enabledness are,
they need to be consistent and to work across scoped logs going in/out of scope.

I think what is needed is a set of connections (logs connect to
appenders/modifiers) ordered by the log name which may include wildcards. Log
name (segments) containing wildcards should be ordered before exact names so
the more specific rules override the less specific ones.

Note the above was from reading the docs + code - I haven't tried running it
yet, and maybe I'm misunderstanding something.


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