From: Bjorn Reese (breese_at_[hidden])
Date: 2019-12-08 15:21:37
On 2019-11-30 17:55, Vinnie Falco wrote:
> When you say "excludes Boost.Serialization style serialization" I
> believe you are referring only to the Parser in the list above.
Not really. I am refering to the ability to create Boost.Serialization
input and output archives.
> Specifically, that a parser which extracts and returns a token at a
> time, rather than consuming the entire input buffer and invoking a
> callback, is a more fundamental building block as it enables more
> use-cases. Please let me know whether this is an accurate
> characterization of your statements. Assuming that it is...
> I disagree with your analysis for these reasons:
> 1. You can always use the JSON value container as the archive with
The whole point of Boost.Serialization is to not go though an
intermediate DOM, but to parse the data directly into the data
structures provided by the user.
> 2. Skipping the value container and archiving from a JSON using a
> token-based parser may be more efficient, but it is dependent on the
> order of keys and thus can no longer be considered JSON, despite
> having the same syntax.
This argument makes no sense at all.
Firstly, JSON Object is unordered, so any key permutation is a valid
syntax. ECMA-404 is quite explicit about this.
Secondly, the json::reader and json::writer processors do not change
the order of key-value pair. If the data structure used by the user
preserves the order, then so will the serialization.
>> That is an incorrect claim.
> And yet you provided evidence to support my claim - the recent changes
> you made to your code require buffering partial inputs.
I do not see how that follows.
I made a single change to the json::reader class in order to support
chunked parsing. This had no performance degradations.
I also added a simple _example_ to show how chunked parsing can be done,
and I even stated that this example could be optimized. However, putting
optimized code in examples tends to obscure the purpose of the example.
There is really nothing that confirms your claim.
> nlohmann's JSON. Instead, they should be using `boost::json::value`,
> the type from my library, because it is more suited as a vocabulary
This is an odd argument to raise here given that Trial.Protocol also
has a vocabulary type, as well as DOM parsing/formatting.
> You said that there is "limited" utility for this use-case but I
> strongly disagree. I get questions all the time about how to use the
I am saying that your JSON library supports less use-case than
Trial.Protocol. Whether or not that is sufficient is a subjective
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk