2011/5/23 Stephan Beal <firstname.lastname@example.org>
On Mon, May 23, 2011 at 1:50 PM, Baptiste Lepilleur <email@example.com>
I propose making the following changes:
1) isUInt() returns true only asUInt() can succeed. Similar changes for isInt().
I think this contract should be generalized. e.g. asUInt() should succeed if the value is a positive signed int Value.
2) Adds new member functions:
isUInt64() that returns true only if asUInt64() can succeed.
If I understood your problem correctly, this should solve your backward compatibility issue. Is that correct?
There was an intermediate version of jsoncpp where the only integers type were int64 / uint64 but this kind of change broke backward compatibility painfully, for example causing printf( "%d", value.asInt()) to behave in "interesting" way.
Also one of the aim of JsonCpp is for use for configuration file. In such case you frequently need to deal with int/ unsigned int types. If the only getter available were 64 bits integer we would be precision loss warning all over the place.
Though if you use asUInt64() you can easily pretend that the other integer type do not exist (minor the identified lack of isUInt64() with the right semantic).
JSON, in fact, does not specify the precision of numeric values (http://www.ietf.org/rfc/rfc4627.txt?number=4627
), probably because it would be impossible to guaranty that any given implementation (in umpteen different programming languages) can honor that, e.g. a certain embedded environment might not have integers >32 bits. Section 2.4 of the JSON RFC notably does not specify any limits on numbers, so 2^75 (when written in expanded integer form) is syntactically legal, according to the grammar, but is almost certainly semantically illegal in any modern computer.
say that in JS integers are reliable up to "15-16" digits (53 bits). Thus int64_t can legally hold any JS-legal value.
Actually, some parser leverage language features that bypass hardware limitation. Python will happily parse a 2^75 integer. Support for use of the arbitrary floating point precision type Decimal was even added at some point in python. So there is clearly use cases around there where people just use JSON for serialization and don't limit themselves to what can be done portably.
 = American slang for "very many"