On 29/07/2015 4:41 a.m., Sönke Ludwig wrote:
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
It was after 3am when I did my initial look. But I saw the appender
usage. I'm ok with this.
The DOM parser on the other hand.. ugh this is where we do need
IAllocator being used. Although by the sounds of it, we would need a map
collection which supports allocators before it can be done.
