Review of Jose Armando Garcia Sancio's std.log

James Miller james at
Mon Feb 13 15:12:16 PST 2012

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.

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.

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.

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

It might not mean much, but this gets my approval.

James Miller

More information about the Digitalmars-d mailing list