On Monday, 20 April 2020 08:04:38 MDT Matthew Woehlke wrote:
> On 19/04/2020 08.23, André Pönitz wrote:
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> >
> > If wanted, this can be refined to make e.g. all integral types comparable.
>
> No:
>
> int{5} <=> JsonObject{...} => lesser
> int{5} <=> long{3} => greater
> long{3} <=> JsonObject{...} => greater
>
> ...oops.
I think, whatever we do, we will keep numeric type conversion. That code is
already there and is the least contentious part of the comparison code. When I
wrote it half a decade ago, I was very careful to follow the C++ integral type
promotion rules. The only new thing I'd do to that code is fix the comparison
of a negative qint64 to a quint64: type promotion rules and expectation don't
match (there's a new function in C++ to do that comparison in the "expected"
manner; can't recall the name).
I would argue that a new QVariant shouldn't even have multiple, different
numeric types, but just one or two (integral and floating point), like
QCborValue does. But since QVariant is built on top of QMetaType, which is
supposed to relate to concrete types in C++ so you can manipulate them in an
erased manner, that's not possible.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
