Hi ----- Original Message ----- > On 03/13/2017 02:15 AM, Markus Armbruster wrote: > > Eric Blake <ebl...@redhat.com> writes: > > > >> On 03/11/2017 07:22 AM, Marc-André Lureau wrote: > >>> The type is not used at all yet. Add some tests to exercice it. > >> > >> s/exercice/exercise/ > >> > >> I wonder if we need this patch at all. > >> > >> I've been thinking about a possible alternative representation, such > >> that a single QInt type can cover _both_ signed and unsigned types, by > >> having QInt track a sign bit bool in addition to a uint64_t value. > >> > > > You say you've been thinking about extending QInt's range to cover > > uint64_t. I've been thinking even more radically: replace both QInt and > > QFloat by QNumber. This is how JSON *actually* works. > > > > The new QNumber type provides constructors from double, int64_t and > > uint64_t. It also provides conversion functions to double, int64_t and > > uint64_t. The latter two can fail. > > Interesting - I like it, as it takes my idea and goes one step further. > You'd want to track 64 bits of precision rather than just 53, when the > input was integral, but the idea seems to have some merit (we have some > special case in the testsuite for what happens in alternates with > various combinations of 'number' vs. 'int' that may need tweaking when > they are no longer distinguishable as QInt vs QFloat, but that's not too > onerous). >
I wonder the benefits from hiding the real type behind a QNumber "superclass", then having to type check at a lower level. QType is not only used for json, so I see some benefits from having a bit stricter type declaration and compile-time check. But I don't have a very good idea of what it would mean to have a generic QNumber type, I could try to implement it to have a more informed opinion. > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
