std.logger

[Robert Schadek]

On 08/22/2013 08:17 PM, Johannes Pfau wrote:
> Am Thu, 22 Aug 2013 20:04:16 +0200
> schrieb Robert Schadek <realburner at gmx.de>:
>
>> On 08/22/2013 07:48 PM, Johannes Pfau wrote:
>>> The problem is that format allocates using the GC. Functions like
>>> writefln can be much more efficient so if the backend is a
>>> FileLogger it could take advantage of that. But IIRC it's not
>>> simple to implement this 'forwarding' with classes / interfaces as
>>> you'll need templated functions...
>> yes, but as you said it is not simple. If it where a template the
>> assignable default logger concept would not work,
>> as it would instantiate the template of the base class. I don't think
>> that this is possible (plz proof me wrong).
>> IMO the default logger concept is more important.
> I've implemented a small logger some time ago and IIRC I couldn't come
> up with a satisfying solution.
>
> The last std.log proposal made a compromise to deal with this: It
> accepted formatted log input but it did call sformat internally before
> passing it to the Logger implementation. The benefit of this was that
> it could reuse the same buffer.
>
> In (pseudo)code:
>
> void logf(Args...)(string fmt, Args args)
> {
>     ubyte[BUFSIZE] buffer;
>     _logger.log(sformat(buffer, fmt, args));
> }
What happens if this throws because of an overflow and you're only
indirectly responsable for the call to logf?
I would rather pass my own static string buffer to log if I fear
performance problems, than to hope
that the buffer in logf is big enough.