Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-09-25 14:06:11

pt., 25 wrz 2020 o 15:10 Zach Laine via Boost <boost_at_[hidden]>

> 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
> > > 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
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?


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