$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-26 14:25:13
On Sat, Sep 26, 2020 at 5:37 AM Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> What's the problem with storing it as a string or as an arbitrary
> number when it's not representable as int64 or a double?
> It doesn't cost anything to do this, it's a pure extension with no
> impact on people that don't need it.
There is a cost. Users who have no need for arbitrary precision
numbers (which is most users) will have a larger executable, paying
for code that never runs.
But there's another cost. Say that a library offers a public member function:
void set_credentials( boost::json::object params );
The library must now deal with the possibility that the user submits
arbitrary precision numbers in `params`. It can't just ignore them, or
else it could be subjected to undefined behavior. It could state as a
precondition "only regular numbers are supported." Either way, the
support for arbitrary precision numbers benefits only a small number
of people but all developers have to be burdened with handling it.
The presence of arbitrary precision numbers in a JSON virtually
guarantees that only a specialized receiver will be able to process
it, as evidenced by the numerous documented warnings about producing
JSON values outside prescribed ranges.
Thanks