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 "error.foo" written to "display" twice. I then say: manipulate_logs("error.*").del_appender("display") 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. Regards Darryl.