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 is 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 the 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 to 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: log4cplus::ConfigureAndWatchThread configureThread(config_file_name, 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 restart. Could add a further global run time and compile time level awareness to minimize the overhead. Matt Hurd.