From: Daniel Frey (d.frey_at_[hidden])
Date: 2019-09-24 14:36:27
> On 23. Sep 2019, at 23:56, Vicram Rajagopalan via Boost <boost_at_[hidden]> wrote:
> On Mon, Sep 23, 2019 at 10:39 AM Vinnie Falco via Boost
> <boost_at_[hidden]> wrote:
>> On Mon, Sep 23, 2019 at 7:51 AM JF via Boost <boost_at_[hidden]> wrote:
>>> I know that it is not standard JSON, but do you plan to support comments
>>> (// ..., /* ... */)? It would be useful for storing configuration
>> I used the same approach with the JSON parser that I used with Beast's
>> HTTP parser. That is, a strict parser which strives to adhere to the
>> letter of the spec.
> I agree with this approach.
> The popular nlohmann::json project made the same design decision, and
> I think their reasoning is quite solid. See here:
If you have a common interface between the different parts (e.g. the SAX-style events interface I mentioned), you can have multiple parsers and you can choose which parser to apply in which situation. In our library we have a strict JSON parser and a parser for a slightly extended JSON format that we call JAXN <https://github.com/stand-art/jaxn> which supports comments, binary data and non-finite values (NaN, Infinity, -Infinity). All other components of the library can be reuse easily and do not depend on the parser. We also have CBOR, UBJSON, MsgPack parsers, you could add TOML or high-performance SIMD parsers, etc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk