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 logging is effected without having called
> this function, all parameters are at their default values and all
> logging 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