[Development] Converting types in Qt
jedrzej.nowacki at digia.com
Wed Jul 16 13:30:11 CEST 2014
On Wednesday 16 of July 2014 12:51:36 Olivier Goffart wrote:
> On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote:
> > Jędrzej Nowacki wrote:
> > > Eike wrote:
> > > > [...]
> > > >
> > > >>> We use common sense on a case by case basic.
> > > >
> > > > Either there is no “common sense” common to me, or this rule has
> > > > failed
> > > > in
> > > > the past already ;)
> > > > bool -> string ?
> > > > bytearray -> int/long/double ?
> > > > keysequence -> int ?
> > > > string -> bool ?
> > > > string -> bytearray ?
> > > > string -> int ?
> > >
> > > What is wrong with string -> int or bytearray -> int?
> > At the very least, _implicit_ conversions should not lose data,
> > i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield
> > a1 == a2.
> > If I am ready to give up information, I'd like to need to say so
> > in the code explicitly. (And yes, part of the deed is done in the
> > core language, but even there compilers start to nag about it.)
> André, QVariant conversions are not implicit, they are explicit.
> You have to use qvariant_cast<T>, QVariant::value<T>, or QVariant::to*.
> That's explicit.
> Conversions _to_ QVariant are sometimes implicit, but they are loss-less as
> it just wrap the type into the QVariant.
True conversions from QVariant are explicit, but some of Qt API hides that,
for example QObject::setProperty which tries hard to implicitly convert data,
Ok, so Andre is in favor of "ideal" conversions (point 1.2). Ideal round trip
conversion is possible only if A and B represent the same concept using a
different representation. So it would work for "QLinkedList<T> <=>
QVector<T>", but not for "int <-> long". In my opinion it is really limiting
and kind of opposite to what we have now :-)
We could potentially split all conversions into two groups "ideal" and "best
effort" and disallow usage of the second group in certain cases. I'm not sure
if it is worth the effort, and definitely It would break existing behavior as
effectively it would remove some of the conversions (point 3)
More information about the Development