Mojmir Svoboda wrote:
The user should be able to specify that at runtime - what if he wants to configure the log at runtime?
no he will _NOT_, that is the beauty ;)) if he still do, let him use log4jpp. according to my (i admit that short perhaps) experiences, this is very rarely needed. you can either modify source and recompile or use log4j++ like i said.
My experience is with large products with many subsystems, worked on by many developers over the course of years. The most effective logging machinery: - Allows you to turn on logging at runtime, so your support person in e-mail dialog with an irritated user can say, "Okay, please set this configuration switch and try that again." Some bugs can only be reproduced on a user's machine. On the other hand, you don't want to generate large log files for every user, every run. - Allows you to be selective about what logging output is produced, because if you turn on EVERYTHING, your user has trouble even storing and mailing you the resulting file -- never mind your problems trying to discover what might be relevant. (This is the result of accumulating helpful logging output in many interacting subsystems over the course of years.) - Has trivial runtime cost for a suppressed log message. In particular, no string allocation or formatting is performed. Ideally, the amortized runtime cost is nothing more than examining a static bool and a jump. There are probably people for whom compile-time controls suffice. But such a library wouldn't be useful to our developers.