From: Matthew Hurd (matt_at_[hidden])
Date: 2004-03-22 08:01:14
> On Behalf Of Simon J. Julier
> I like this approach and I personally think that setting logging levels in
> any specific part of a program is a must. The reason (which might say bad
> things about how we write software!) is that in my experience different
> libraries have different levels of maturity and hence different levels of
> logging. e.g., library X is fairly mature and needs very little logging.
> library Y is semi-mature and needs reasonably verbose logging. library Z
> brand new and should be logged exhaustively. Anything which uses a global
> approach would force all log statements to the highest common demoninator
> and would force everything to be extremely verbose. Furthermore, having
> option to compile out logging statements means that people can leave a lot
> of logging hard coded into the code simply because there is no incentive
> remove it. (Which everybody finds out when you enable logging again....)
It is also nice when you can turn logging levels up and down without
restarting your app, though you still want the option to compile it out of
there for some sections of code. I find having inherited loggers handy to
partition which loggers are being turned on, usually along the lines of
namespace.namespace2.class...., but whatever suits your app.
log4cplus, for example, can use this approach:
seconds_to_wait_before_polling * 1000);
where is spins off a thread to watch your config file which suits some
styles of apps.
Change your config file, wait the poll time and your logging level has
changed. Can be useful especially when you write dumb code like I'm prone
too ;-) Esp. handy when you can add a remote logger into the mix without a
Could add a further global run time and compile time level awareness to
minimize the overhead.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk