Implementing std.log

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun May 15 15:55:50 PDT 2011


On 05/15/2011 10:53 AM, Jens Mueller wrote:
> Andrei Alexandrescu wrote:
>> 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);
>>      ...
>> }
>
> How do you plan to do this?
> Because it looks partly what gflags is doing. At least it would be
> useful as general feature for handling program options.
> I haven't found a way to define flags in a compilation unit as gflags
> does. I have code that generates a help string and even reading flags
> from a files is easy. But I have no clue yet how to allow declaring
> flags in different compilation units. Technically I'd like to allow each
> flag that can be handled by std.getopt but I have no idea how to check
> whether getopt supports a given flag. If I knew I'd store flags in
> associative array where values are Algebratic!(GetoptFlagTypes).
>
> Jens

The way the Google flags library does that is by planting registration 
functions globally. Then initGoogle(argc, argv) at the beginning of main 
takes care of calling all registration functions.

We could add such a hooking capability to getopt, but the current 
std.log design doesn't need one - it just calls getopt itself and cherry 
picks the parameters it's interested in.


Andrei


More information about the Digitalmars-d mailing list