On 12/02/2015 08:42, Knoll Lars wrote:
Yes, 80 or 128bit doubles are out of the question. The RFC basically
doesn’t specify the range of allowed values, but hints that it should at
least support doubles. We can go above that and allow 64bit integers as
well as they are rather common these
Il 11/02/2015 16:11, Marc Mutz ha scritto:
If Qt produces 64-bit integers in its JSON output, then the next bug report
will (probably rightfully) be that Qt's JSON output cannot be read by some
JavaScript library X.
Note that it's perfectly legal, and a feature of JSON:
On Wednesday 11 February 2015 12:12:33 Bo Thorsen wrote:
If I say to my customers they have to send me another language because
the Qt JSON library can't read 64 bit unsigned integers they say Qt
sucks, switch to another JSON library.. We can't win here.
What's to stop someone at 64-bit?
Marc Mutz schreef op 11-2-2015 om 16:11:
On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote:
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
On 11 February 2015 at 12:12, Bo Thorsen b...@vikingsoft.eu wrote:
It's so easy to say we just follow the standard. But I have two current
On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote:
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
On 11 February 2015 at 12:12, Bo Thorsen b...@vikingsoft.eu wrote:
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me
On Wednesday 11 February 2015 17:42:54 Giuseppe D'Angelo wrote:
Il 11/02/2015 16:11, Marc Mutz ha scritto:
If Qt produces 64-bit integers in its JSON output, then the next bug
report will (probably rightfully) be that Qt's JSON output cannot be
read by some JavaScript library X.
Note
On Wednesday 11 February 2015 21:26:40 Marc Mutz wrote:
The interesting part is what Qt should do about it. Postel's Law clearly
asks
for accepting (even invalid) input as long as its meaning is clear. Clearly,
that is the case for larger-than-double numbers. So, by Postel's Law, Qt
should
On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote:
On Wednesday 11 February 2015, Marc Mutz wrote:
If long double was any useful (apparently it's no larger than double on
Windows), we could use that, but as it stands, that would be pointless.
Apropos, the usefulness of
On Thursday 12 February 2015, Marc Mutz wrote:
On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote:
On Wednesday 11 February 2015, Marc Mutz wrote:
If long double was any useful (apparently it's no larger than double on
Windows), we could use that, but as it stands, that
On Wednesday 11 February 2015, Marc Mutz wrote:
If long double was any useful (apparently it's no larger than double on
Windows), we could use that, but as it stands, that would be pointless.
Apropos, the usefulness of extended precision floating point happens to be
that they can represent
On Thursday 12 February 2015 01:18:47 Allan Sandfeld Jensen wrote:
On Thursday 12 February 2015, Marc Mutz wrote:
On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote:
On Wednesday 11 February 2015, Marc Mutz wrote:
If long double was any useful (apparently it's no larger
On 12/02/15 04:08, Thiago Macieira thiago.macie...@intel.com wrote:
On Thursday 12 February 2015 01:18:47 Allan Sandfeld Jensen wrote:
On Thursday 12 February 2015, Marc Mutz wrote:
On Thursday 12 February 2015 00:18:28 Allan Sandfeld Jensen wrote:
On Wednesday 11 February 2015, Marc Mutz
Hi guys,
ATM QJsonValue doesn't have a way to read a 64 bit integer or unsigned
integers. The standards doesn't seem to limit the contents of an int.
And I know of several projects that use this.
{i:1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to
On 11 February 2015 at 11:40, Bo Thorsen b...@vikingsoft.eu wrote:
{i:1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to variant, it gives me a double.
Because it _is_ a double, given that JSON is a subset of Javascript,
and numbers in Javascript are IEEE754
Den 11-02-2015 kl. 11:58 skrev Giuseppe D'Angelo:
On 11 February 2015 at 11:40, Bo Thorsen b...@vikingsoft.eu wrote:
{i:1e33} gives a 0 if I convert the number to int (which is fair
enough). If I convert to variant, it gives me a double.
Because it _is_ a double, given that JSON is a subset
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
On 11 February 2015 at 12:12, Bo Thorsen b...@vikingsoft.eu wrote:
It's so easy to say we just follow the standard. But I have two current
projects where my customers say they send me a 64 bit database ID in a JSON
value. Converting those
16 matches
Mail list logo
