Walter Bright <newshou...@digitalmars.com> wrote in news:i574ns$11t...@digitalmars.com:
> > Ok, I'm going to get flamed for this, but, > > I don't get it > > I do logging all the time. It's usually customized to the particular > problem I'm trying to solve, so it involves uncommenting the right > printf's and then running it. Voila. Done. > > The logging libraries I've seen usually required more time spent > installing the package, getting it to compile, reading the > documentation, finding out it doesn't work, rereading the > documentation, etc., etc., than just putting in a #...@$%^ printf, and > Bang, it works, cut & print. > > Even worse, the logging libraries are loaded with a grab bag of > trivial features to try and puff it up into looking impressive. They > always seemed to me to be a solution in search of a problem. > > Shields up! what am I missing about this? In general, I would tend to agree that some logging libraries are pretty complicated and hard to just dive in and build what you need without spending a week learning the library. However, in commercial applications, espcially servers, there is often the need for standardized logging messages that are really part of the server's output and not just something for one off debugging. Think in terms of inetd, smtpd, or some commercial server. These need to continually log messages containing one or more of timestamp, location of where message originated, severity of message (note, error, warning, etc), thread id, and other things I am not thinking of at the moment. :) Furthermore, the output may get targeted to multiple streams such as console, debug out on windows, files, one of the system event logs. Furthermore, files may roll like the unix system log based on some criteria (size, date). Etc. There are a lot of things to consider. A good approachable library can make assembling the right combination of logs pretty simple. Many people consider it important to be able to turn the logging off and leave minimal overhead (I personally find that applications that need logging, really just want to leave it on, even if the programmer's don't think they do. Bugs are often time consuming to reproduce and your customer may not be thrilled with the prospect of helping you find your bug.) There are probably other things I am forgetting, but hopefully you get the idea. So, anyway, I can see the need for a logging construction kit of some sort. Ideally though, it would make things easy to construct a log that does what you need without spending a week learning the library. :) joe