On Mon, Sep 23, 2019 at 2:19 AM Dominique Devienne via Boost
What about performance?
I have not run any benchmarks, or invested any time in optimizing the code. My main efforts thus far have been making sure that the public interfaces are correct, and that things work.
Have you heard of https://github.com/lemire/simdjson?
Yes I have seen that library. It is more of a proof-of-concept, and it has the requirement that it requires the entire JSON documented to be presented in a single contiguous input. For many use-cases, this condition is acceptable. So I have designed the parser to be informed when the condition is met, and use a different algorithm such as the SIMD one above.
a PULL-parser that allows to build the native data-structures directly, rather than the DOM-like approach of fully converting the document to a built-in JSON object
Yes, the JSON parser and the HTTP parser (in Beast) both are implemented with an event-style interface and do not make assumptions about the container used to store the data (this is provided by a subclass). See: https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb93... https://github.com/vinniefalco/json/blob/25ddea5f4d088f3e56911bf9f97549eeb93...
Finally, there are many corner cases in JSON parsing. Is there the equivalent of Autobabhn for WebSocket, but for JSON parsing?
No idea, but if anyone knows of such a facility please let me know :)
Any plans to integrate with such infrastructure, assuming there's one?
Sure! Thanks