Boost logo

Boost :

From: Lee Clagett (forum_at_[hidden])
Date: 2019-12-08 22:56:28

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 8, 2019 3:48 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:

> Bjorn Reese wrote:
> > 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.
> As I already stated in a previous message, if your reader can only read what
> your writer writes, your format is JSON in name only. A "real" JSON reader
> must be able to read not just the literal output of the writer, but a
> modified JSON file that is (per spec) equivalent to the original. Which
> includes reordered fields, as you yourself wrote in the very previous
> paragraph.

This response could've easily been to Vinnie as well. I believe what
Bjorn was mentioning -

The reader can assume the same order, until it misses a field and then
buffers into a generic json::value. In some use cases, the order will
always be the same since the application will use the same
implementation for reading and writing. I also mentioned earlier in the
thread that higher performance will frequently (nearly always) be with
linear searching the fields of a struct compared to using a generic
data structure and moving/copying. This does require an interface that
isn't typical of existing JSON parsers (something template variadic
most likely). Vinnie refuted the latter approach, claiming that the
JSON parser was not designed to suit all needs.

A "pull" parser will allow for the typical generic interface, a
SAX/push parser interface, and allow advanced users to use either of
the techniques described in the above paragraph. I believe Bjorn and
Vinícius are both arguing for this type of parser, and if so I agree
with them.

> > Firstly, JSON Object is unordered, so any key permutation is a valid
> > syntax. ECMA-404 is quite explicit about this.


Boost list run by bdawes at, gregod at, cpdaniel at, john at