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
On 12/02/15 04:08, "Thiago Macieira" 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 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 wrote:
> > > > If long double was any useful (apparently it's no
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,
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 use
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 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
> shoul
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.
>
>
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?
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:
https://tools.ietf.or
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 wrote:
It's so easy to say we just follow the standard. But I have two current
projects wh
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 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 d
Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo:
> On 11 February 2015 at 12:12, Bo Thorsen 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 through a doub
On 11 February 2015 at 12:12, Bo Thorsen 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 through a double might work, but can you guarantee
> this?
No, becaus
Den 11-02-2015 kl. 11:58 skrev Giuseppe D'Angelo:
> On 11 February 2015 at 11:40, Bo Thorsen 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 Javascri
On 11 February 2015 at 11:40, Bo Thorsen 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 64bit floating
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 varian
17 matches
Mail list logo
