Implementing std.log

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat May 14 15:35:32 PDT 2011


On 05/14/2011 04:56 PM, 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'll also question whether they should be written to files at all by
> default (as opposed to stdin and stderr). I'm aware initLogging's
> documentation says: "If log­ging is ef­fected with­out hav­ing called
> this func­tion, all pa­ra­me­ters are at their de­fault val­ues and all
> log­ging is done only to stderr." So basically, I'll get what I want if
> I never call initLogging, but then I can't control verbosity and other
> settings using --v and other flags passed as arguments.

A server app must log to files, no question about that. We'll need to 
add rotation etc. in the future. But I do plan to offer ways to manually 
override defaults, e.g.:

void main(string[] args)
{
     logtostderr = true; // override default
     initLogging(args);
     ...
}


Andrei


More information about the Digitalmars-d mailing list