Implementing std.log

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun May 15 16:01:54 PDT 2011


On 05/15/2011 10:26 AM, Jacob Carlborg wrote:
> On 2011-05-15 00:33, Andrei Alexandrescu wrote:
>> On 05/14/2011 05:17 PM, Jonathan M Davis wrote:
>>> On 2011-05-14 14:56, Michel Fortin wrote:
>>>> On 2011-05-14 17:31:30 -0400, Jonathan M Davis<jmdavisProg at gmx.com>
>>>> said:
>>>>> So, I do think that knowing which thread is logging what could be very
>>>>> important for some programs, but I don't think that separating the log
>>>>> files is necessarily a good idea. If you did, you'd lose timing
>>>>> information (unless the time is at the beginning of every log line
>>>>> (which could also be useful), but then you'd have to read the times
>>>>> and
>>>>> compare them to see what happened before what). So, I'd be all for
>>>>> some
>>>>> options and extra information which could be added to each log line
>>>>> which would help debugging, but I don't think that thread-local
>>>>> logs is
>>>>> a great idea.
>>>>
>>>> I'd even go further and question whether it makes sense to have info,
>>>> warning, and errors be written to separate files.
>>>
>>> I'd definitely vote for them all to be in the same file, but I don't
>>> generally
>>> see much benefit in having multiple log files. I like having them all
>>> in one
>>> place where you can see what happened in what order. Having them in
>>> separate
>>> log files is just going to make it harder to figure out what happened,
>>> and I
>>> think that it would become tempting (for me at least) to just log
>>> everything
>>> at exactly the same level so that they ended up in the same file.
>>
>> The info log contains log messages for all levels.
>>
>> Generally I'd want to stray from glog's major design decision as little
>> as possible. It's an approach validated by years of experience in
>> heavy-duty applications. Also, people coming from glog and used to its
>> features would find it unpleasant that we decided to do things a
>> different way without solid reasons.
>>
>>
>> Andrei
>
> Why not? It doesn't say anywhere in the documentation, as far as I can
> see, that it's based on glog.

That's beside the point as the documentation could and should be 
changed. I've said repeatedly it's based on glog, and I think it's a 
good thing.

> I think that, in general, that is a poor
> argument: "Because library A does it like that we also have to do it
> like that". What about all people coming from library B, C, D and so on,
> it will be unpleasant for those as well because we didn't follow their
> particular library design.

It's a good argument if library A is considered better by the person 
making the argument than B, C, and D. One thing is that glog has most 
desirable qualities I am looking for in a logging library: allows 
compile-time and run-time enabling/disabling, it's relatively small, 
it's simple, it's effective, and is widely used. I'm sure there are 
other libraries that score better on either dimension, but not on all.

There are two departures I chose to make from glog: (a) I added the 
critical log which throws an exceptions (Google wouldn't need one 
because they don't use exceptions), and (b) I replaced the clunky 
LOG_IF_EVERY_N etc. with the flexible when(), every(), after() etc. I 
think these are well justified choices.


Andrei


More information about the Digitalmars-d mailing list