Implementing std.log

Jacob Carlborg doob at me.com
Sun May 15 08:26:51 PDT 2011


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. 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.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list