== Quote from Yao G. ([email protected])'s article > On Thu, 26 Aug 2010 20:34:43 -0500, Walter Bright > <[email protected]> wrote: > > > > 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? > Using printf / writeln is perfectly fine, until you start to program in > Windows, where there's no command line to display the text. Here's where I > think a small logging library comes handy. I did a small one that logs to > a file, and a variant that display the log messages to a independent > window.
Ok, how about just having a global File object (in D2) that either points to a real disk file or stdout/stderr, depending on the circumstances?
