On 27-Sep-2015 20:43, Marco Leise wrote:
Am Mon, 03 Aug 2015 12:11:14 +0300
schrieb Dmitry Olshansky <[email protected]>:
[...]
Now back to our land let's look at say rapidJSON.
It MAY seem to handle big integers:
https://github.com/miloyip/rapidjson/blob/master/include/rapidjson/internal/biginteger.h
But it's used only to parse doubles:
https://github.com/miloyip/rapidjson/pull/137
Anyhow the API says it all - only integers up to 64bit and doubles:
http://rapidjson.org/md_doc_sax.html#Handler
Pretty much what I expect by default.
And plz-plz don't hardcode BitInteger in JSON parser, it's slow plus it
causes epic code bloat as Don already pointed out.
I would take RapidJSON with a grain of salt, its main goal is
to be the fastest JSON parser. Nothing wrong with that, but
BigInt and fast doesn't naturally match and the C standard
library also doesn't come with a BigInt type that could
conveniently be plugged in.
Yes, yet support should be optional.
Please compare again with JSON parsers in languages that
provide BigInts, e.g. Ruby:
http://ruby-doc.org/stdlib-1.9.3/libdoc/json/rdoc/JSON/Ext/Generator/GeneratorMethods/Bignum.html
Optional ok, but no support at all would be so 90s.
Agreed. Still keep in mind the whole reason that Ruby supports it is
because its "integer" type is multi-precision by default. So if your
native integer type is multi-precision than indeed why add a special
case for fixnums.
My impression is that the standard wants to allow JSON being
used in environments that cannot provide BigInt support, but a
modern language for PCs with a BigInt module should totally
support reading long integers and be able to do proper
rounding of double values. I thought about reading two
BigInts: one for the significand and one for the
base-10 exponent, so you don't need a BigFloat but have the
full accuracy from the textual string still as x*10^y.
All of that is sensible ... in the slow code path. The common path must
be simple and lean, bigints are certainly an exception rather then the
rule. Therefore support for big int should not come at the expense for
other use cases. Also - pluggability should allow me to e.g. use my own
"big" decimal floating point.
--
Dmitry Olshansky
