Review of Jose Armando Garcia Sancio's std.log

Jose Armando Garcia jsancio at
Mon Feb 13 18:52:51 PST 2012

On Mon, Feb 13, 2012 at 9:12 PM, James Miller <james at> wrote:
> On 14 February 2012 10:17, Sönke Ludwig
> <ludwig at> wrote:
>> Log levels "debug" and maybe also "trace" would be useful, but I see that
>> vlog(n)() is meant for that purpose. I would just prefer explicit names
>> instead of just numbers.
>> Is there a compelling reason why formatted logging is not the default? I
>> find that most logging calls in practice use formatted output, and the only
>> overhead would be searching once through the format string in the case of
>> format placeholders.
>> A predefined logger for OutputDebugString on Windows would be useful - or
>> maybe it could be used instead of stdout at least for non-console
>> applications.
>> One kind of log writer that I have in my code is one that outputs a nicely
>> formatted HTML file with built-in JavaScript to be able to filter messages
>> by priority or module. Maybe this is too much for a standard library
>> implementation though.
>> Support for multiple log writers can be useful (e.g. logging to a file +
>> logging to stdout or to a log control inside of the running application). Of
>> course, one can also simply write a "MultiDispatchLogger"...
>> A format option to log the thread name instead of just the ID.
> I agree that there needs to be an easy to use format-based logger,
> even if its just logf template that calls format on the filter, since
> writing `log!(info).format("my string %s", s);` looks bad compared to
> `logf!info("my string %s", s);`
> Looking through the docs, there needs to be a better indication of
> configuration in the primary example, since you don't even mention it,
> I thought it might not exist.
At the top of the documentation I wanted information on how to use the
module for the common developer. To me the common developer is going
to write log message not configure the log module/framework.

The user that is going to configure the library can read the whole
document or the Configuration classes.


> A built-in console logger should probably be available, one that
> writes to stdout at the very least, since I often need log messages
> for debugging, other loggers can be build on top of the Logger
> interface, separate from the library, but I imagine that many people
> would want a console logger and doing it in the standard library will
> prevent too much repeated work. It would also be an idea to make it
> the default, but at this point I can't really separate out my
> practices from what I think most people do.
The default FileLogger can do this. See --logtostderr,
--alsologtostderr and --stderrthreshold.

> A debug-level log would be nice, but I don't really care either way.
> A built-in MultiDispatchLogger (or similar) would be nice, but I don't
> think it really matters.
Yeah. We could use a few other loggers. But we should think of this as
a living module. The most important thing I think is that we can make
this future improvements without breaking existing users.

> Otherwise, I think it all looks good; fairly simple to use and
> configure, ability to override the defaults if needed, ability to swap
> out backends at runtime. The docs need work, but docs always need work
> :P.
> It might not mean much, but this gets my approval.
> James Miller

More information about the Digitalmars-d mailing list