|
Boost : |
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2020-09-25 14:12:18
On Fri, Sep 25, 2020 at 9:07 AM Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
>
> pt., 25 wrz 2020 o 15:10 Zach Laine via Boost <boost_at_[hidden]>
> napisaÅ(a):
>
> > On Fri, Sep 25, 2020 at 6:11 AM Mathias Gaunard via Boost
> > <boost_at_[hidden]> wrote:
> > >
> > > On Thu, 24 Sep 2020 at 10:57, Andrzej Krzemienski via Boost
> > > <boost_at_[hidden]> wrote:
> > >
> > > > My understanding of a "vocabulary type" is that it should be usable
> > (not
> > > > necessarily with maximum efficiency) for *any* usage. In the case of
> > JSON
> > > > that would mean that I should be able to represent any value that
> > > > corresponds to a valid JSON when converted to text. I do not think that
> > > > json::value can claim that without the ability to serialize
> > arbitrarily big
> > > > numbers.
> > >
> > > I fully agree with this statement.
> > > json::value *needs* to support arbitrary numbers. It's incomplete
> > without it.
> > > Maybe the author of multiprecision can advise on the best type to use
> > > there (gmp or mpfr?).
> >
> > This is not a reasonable requirement. std::string is the canonical
> > C++ vocabulary type. On 32-bit systems, it cannot represent 5GB-long
> > strings. Depending on platform limitations, it usually cannot even
> > represent more than 2GB-long strings. Computers are limited to finite
> > resources. Putting finite limits on the representation of all kinds
> > of values is normal, not unexpected -- this is especially true of
> > numeric values.
> >
>
> I am wondering. If I have a small web service for generating prime numbers,
> and I need to return them in a JSON file, is my only option to pass it as
> string?
> Prime numbers of this kind are bigger than uint64_t. But they are not as
> big as 1MB. Is such a use case for a number so unusual that it cannot be
> stored as a JSON number?
> Are JSON numbers only good for storing int-based identifiers?
I don't know what an int-based identifier is, but I do know that the
use cases for machine-representable ints (that is, and int that is the
size of an int, fits in a register, etc.) is >99% and the use cases
for a web service that generates prime numbers is <1%. That's what
should drive the design.
Zach
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk