|
Boost : |
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-09-24 13:11:05
On Tue, Sep 24, 2019 at 2:29 AM Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Features that matter to me:
> - no allocation, ever
> - parsing/generating data incrementally from/into segmented buffers
> without copying
> - full arbitrary-precision decimal support without imposing a decimal
> representation on me
> - not imposing any string or blob type
> - fast conversion between numbers and text, with correct shortest
> representation for floating-point
These are all features of a JSON parser. As I said earlier, I think
the parser is the least interesting part of a JSON library. There are
already a bunch of parsers that do exactly what you are asking above.
Since parsers are unlikely to appear in public interfaces, there is
little value in standardizing on a particular one. Library
interoperability is not enhanced in this case.
What we are missing, is a robust *container* for storing JSON values.
Having a great container for representing all or part of a JSON
document does make it easier to write interoperable library components
that work with JSON. A library that implements the JSON-RPC
specification [1] may have a function with this signature:
// Validates and extracts a conforming JSON-RPC request from the
// specified JSON object. Throws an exception if the request is not
// conforming
rpc_call get_rpc_request (boost::json::value& jv);
For this to work, boost::json::value needs to be a good general
purpose JSON container that satisfies most users. We can never satisfy
ALL users; some design choices must represent tradeoffs between
conflicting goals. The library I am providing, to propose to Boost
eventually, places emphasis on the design of the JSON container
because this is the surface which will be exposed between libraries.
It is this part that hopefully will stimulate the growth of an
ecosystem of libraries which use JSON and interoperate.
A final example, someone may use Boost.Beast and Boost.JSON to
implement a generic RPC client or server library, taking care of the
socket and connection management, making requests and receiving
responses. Users of such a library will care little about the parser
it uses, other than that it exists and works. But they will care very
much about the types used to represent JSON data, since they will be
interacting with it regularly to implement their business logic.
Regards
[1] <https://www.jsonrpc.org/specification>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk