std.data.json formal review

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 28 09:41:50 PDT 2015


Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
> On 29/07/2015 2:07 a.m., Atila Neves wrote:
>> Start of the two week process, folks.
>>
>> Code: https://github.com/s-ludwig/std_data_json
>> Docs: http://s-ludwig.github.io/std_data_json/
>>
>> Atila
>
> Right now, my view is no.
> Unless there is some sort of proof that it will work with allocators.
>
> I have used the code from vibe.d days so its not an issue of how well it
> works nor nit picky. Just can I pass it an allocator (optionally) and
> have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory
> allocated during a request then you know, rely on the GC.

If you pass a string or byte array as input, then there will be no 
allocations at all (the interface is @nogc).

For other cases it supports custom allocation through an appender 
factory [1][2], since there is no standard allocator interface, yet. But 
since that's the only place where memory is allocated (apart from lower 
level code, such as BigInt), as soon as Appender supports custom 
allocators, or you write your own appender, the JSON parser will, too.

Only if you use the DOM parser, there will be some inevitable GC 
allocations, because the DOM representation uses dynamic and associative 
arrays.

1: 
https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/lexer.d#L66
2: 
https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/parser.d#L286


More information about the Digitalmars-d mailing list