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