On Sun, Dec 8, 2019 at 7:21 AM Bjorn Reese via Boost
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.
Then I am understanding you correctly. You claim that Trial.Protocol is more suited than Boost.JSON for integration with Boost.Serialization, because of the parser interface. I don't think this is correct for the case of going directly to a user-defined type, for the reason I stated earlier which you agree with: that JSON does not prescribe the ordering of elements of objects. Consider a simple struct with members a, b, and c. We might archive it this way: a & BOOST_SERIALIZATION_NVP("a", a); b & BOOST_SERIALIZATION_NVP("b", b); c & BOOST_SERIALIZATION_NVP("c", c); The resulting JSON might look like this: { "a" : 1, "b" : 2, "c" : 3 } However, a perfectly valid encoding for an identical object could look like this: { "c" : 3, "b" : 2, "a" : 1 } In this case the serialization code above will not function correctly given the alternate encoding of the JSON, because the code assumes that the order of keys will be the same as when it was serialized. An obvious solution is to parse into the intermediate DOM. JSON is not an appropriate archive format for serialization, for the reason that the order is not prescribed. You could implement a Boost.Serialization archive for it, and the result would have the *format* of JSON but it would not have the same semantics. Thus it cannot really be considered JSON. And if we are going to choose a format which is not-JSON, there are many better formats with less overhead.
Firstly, JSON Object is unordered, so any key permutation is a valid syntax. ECMA-404 is quite explicit about this.
Exactly.
If the data structure used by the user preserves the order, then so will the serialization.
Exactly. "if" the order of keys in the archive is preserved, then it works. This is "not-JSON." The use-case for a JSON serialization archive is not for the same program to round-trip the data, otherwise there are more efficient formats as I stated above. A useful use-case would be to serialize a user-defined type T to JSON, in a way that other programs can access, even if the keys are reordered. And to go the other way, from an external program that produces a JSON, to deserializing into a user-defined type T, even if the keys are reordered. A typical example is a C++ server communicating with a JavaScript/HTML5 client. The JavaScript program doesn't know about and doesn't care about Boost.Serialization, nor does it preserve the order of keys.
Your parser currently uses stack variables, so the adaptor has to use stackful coroutines which would incur two context-switches on every iteration.
I was referring to stackless coroutines. That type of coroutine still has stack variables. It just doesn't save the entire stack at a suspend point. The compiler can turn any function which has statically bounded stack requirements into a "stackless coroutine." Thanks