On 2019-11-24 16:30, Vinnie Falco wrote:
I'm not seeing where trial.protocol has incremental algorithms, perhaps you can show me? trial::protocol::json::basic_reader constructs with the complete input:
You are right. Chunked parsing was missing. The json::reader is a low level API that does not manage buffers, but it does indeed lack a function for updating the view without resetting the other state (the nesting levels.) Fortunately that is a trivial change, which I have just added for your pleasure, along with an example of chunked parsing that is akin to yours: https://github.com/breese/trial.protocol/commit/681afed05f32eb5288d6703d5537... Buffer management can obviously be optimized in the example.
I disagree. Again the central premise here is that there is no ideal JSON library which can suit all needs. I believe this is why Boost does not yet have a JSON library. Optimizing one use-case necessarily
Maybe there is no single JSON library that suits all needs. However, your JSON library supports a rather limited set of use-cases that excludes Boost.Serialization style serialization, whereas Trial.Protocol supports the same use-cases and many more with simpler building-blocks.
comes at the expense of others. At the very least, the inversion of the flow of control (i.e. a parser which returns a token at a time) advantages one use case and disadvantages others (such as working as an online algorithm). There are other tradeoffs. Because my library
That is an incorrect claim. Both push and pull parsers needs to parse tokens one by one and keep state information. You do not have to take my word for it; here is what Thiago Macieira had to say about it: "First of all, the type information is there anyway. The only difference is whether it is exposed to the user in the API or whether it's hidden. In the SAX case, because of the push-style API, it's hidden and the parser does the switching for you and calls your function. Second, you must provide something like an iterator anyway if you want to provide some type properties to the visited function. Properties like array size, string length, etc. That is required if you want to implement string zero-copy. [...] Mark my words: the SAX parser will be implemented on top of the StAX one." From https://groups.google.com/a/isocpp.org/d/msg/std-proposals/JNZzOvC7llo/l1DVh... And just confirm his "mark my works" comment, this is how simple it is to create a push parser with a pull parser: https://github.com/breese/trial.protocol/blob/develop/example/json/push_pars...