OT: std.logger was Re: std.experimental Timeline

[Robert burner Schadek via Digitalmars-d]

On Monday, 4 January 2016 at 10:58:09 UTC, Jonathan M Davis wrote:
> If I understand correctly (based on previous statements by 
> Dicebot), the problem is that at Sociomantic, they reuse 
> buffers heavily. So, they basically don't use string much of 
> anywhere and instead use some combination of char[] and 
> const(char)[] (so that the array elements can be given new 
> values without reallocating), and std.experimental.logger - 
> like a lot of typical D code - uses string, which means that 
> when they log a message with std.experimental.logger, their 
> buffer has to be copied into a string, which means that an 
> allocation occurs, which in their environment is unacceptable.

FileLogger is a Logger that can be used after only one allocation.

new FileLogger;

Everything else (logging, ...) does not require a single 
allocation.
If you look at the documentation above [1] you will understand 
why.

Building a MultiLogger (Logger of Loggers) that forwards the 
calls to the log functions to the contained Loggers without 
allocation is also trivial.
Logging into a passed in buffer is also trivial (as long as you 
buffer is big enough for the data to log, but that is design 
problem).

>
> So, to work for them, they would need std.experimental.logger 
> to accept something like const(char)[] or an arbitrary ranges 
> of characters and to not allocate inside of any of its logging 
> functions. Any requirement to convert to string (be it by the 
> user of the logger or inside of the logger itself) doesn't work 
> with their requirements.

as said above, no Logger has to allocate for logging, and no 
string has to be created.

An allocation schema was selected however, to make multi 
threading work by default.
Creating a user specific Logger that fits the Logger interface 
and that uses a static buffer to write the data to is properly 
less than 20 lines of code.

>
> I'm not particularly familiar with std.experimental.logger as 
> it stands, by I would guess that to fit Sociomantic's 
> requirements, it would need to either manage to log without 
> actually constructing any array of characters (e.g. by printing 
> each of its elements in turn without actually putting them 
> together first), or it would need to reuse a buffer every time 
> it created the line to log (which would incur the cost of 
> copying the characters but wouldn't normally have to allocate). 
> But I don't know how well that fits in with the logger being 
> hierarchical via classes (which solves other design 
> requirements) or how close the current implementation is to 
> that. Certainly, being forced to use classes does prevent the 
> logger from using some of the typical techniques that we use 
> (particularly with regards to ranges). So, the logger 
> definitely presents some challenges that most other Phobos code 
> doesn't have to deal with. :| Though obviously, you'd be more 
> aware of that than anyone. :)
>
> - Jonathan M Davis

If you guess of their requirements is correct, 
std.experimental.logger fulfills the requirements.

[1] 
https://github.com/D-Programming-language/phobos/blob/master/std/experimental/logger/core.d#L812