Voting: std.logger

[Jakob Ovrum via Digitalmars-d]

On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:
> ====================================
> Jakob Ovrum
> ====================================
>
> "The *API* must support minimal dynamic memory allocation for
> the normal execution path. However, theoretical *implementation*
> changes that reduce memory allocation are not a deal-breaker."
>
> This seems to be addressed but though it is desired to verify 
> it via @nogc unittest block which uses stub no-op logger (to 
> verify that nothing in between allocates). One place were GC 
> allocations is unavoidable is core.d:1628 - it will always 
> create FileLogger first and allow assigning custom one later. 
> Is there any way to circumvent it?

Yes - split the `stdlog` property into a getter and a setter. 
Then if the setter is called first (with a non-null reference), 
the getter never gets to allocate the default instance. I pointed 
this out in a line comment before, but I guess it disappeared due 
to the name change...

Also, as I said in the line comment, it doesn't need to 
GC-allocate, it can allocate in global memory or TLS using 
emplace (which of them is appropriate depends on the threading 
model, I guess...). If Andrei's reference-counting suggestion is 
implemented, then depending on the details, it's possible that 
the default logger could be allocated on the C heap instead of 
the GC heap as well, managed by RC.