I can't disagree more with this. IMO, logging is not at all a way to give information to the program user. In my mind, a logging library is intended only for debugging, journaling, auditing and performance measuring. Not a way to display error message or waiting message to the user. In my mind, these are totally different things. Please someone, give his POV on this, I think this is a major disagreement.
I think this establishes two distinct uses for logging. I am thinking about logging in terms of (say) an application like Apache web server. The *user* likes to have tidy logs generated to let them know who is accessing the server, how and when. These log files are formatted and available to be fed into other applications that can produce nice statistics and graphs. To me this is what I mean by 'logging'. What you are talking about is trace debugging. For this activity I think using the logger is perfectly valid. This is an area where you might make most legitimate use of macros. But to my mind, as far as 'logging' is concerned it is only a 'niche' usage. The problem is that many developers only really use logging for this purpose and this is all they want from a logging system. However there are many medium to large systems out there that utilise logging as a core function/side-effect of their activity. Now for programmers with the task of writing these business and enterprise class applications that expect reliable and accurate logs, capable of driving statistical analysis, billing engines and the like, a standard, flexible and extensible library would be of great benefit. So it is possible we have two tasks here. 1) A basic development/debugging tool 2) A fully competent systems logging library. Now my interest lies in the second of these though I also want to be able to do the first. It would be nice to think that the one could be derived from the other for consistency. After all as a developer why use two logging systems when you can use one?