[Development] Converting types in Qt
apoenitz at t-online.de
Thu Jul 17 21:31:31 CEST 2014
On Thu, Jul 17, 2014 at 02:36:22PM +0200, Olivier Goffart wrote:
> On Thursday 17 July 2014 13:33:49 Daniel Teske wrote:
> > A equals operator that is not symetric is broken. Such a class cannot be
> > reliably used in std nor qt containers. Or do you know which way around,
> > QList::contains uses the equals operation?
> Note that none of the class which have a member operator== is symmetric.
> Most of the class had an operator== as a member in Qt4 but that was a design
> mistake. New classes should have a friend operator== instead.
> qDebug() << (QUrl() == QString()); // true
> qDebug() << (QString() == QUrl()); // compilation error
> That's because QUrl has a
"because" is the bigger half of a red herring here.
> bool QUrl::operator==(const QUrl&);
> Instead of
> bool operator==(const QUrl &, const QUrl&);
> The later is symmetric, but the former is not.
The fact that the former is asymmetric is indeed not nice, already for
esthetic reasons. But the fact that it actually _hurts_ is only due to the
non-explicit QUrl(const QString &url, ParsingMode mode = TolerantMode)
If that is not available, e.g. after #define QT_NO_URL_CAST_FROM_STRING,
neither version compiles. That's symmetric, and good.
> This is also valid for operator< and related.
> (That was just to go a bit more out of topic :-))
We are still on track. The topic is "free type conversion cause trouble",
or "Why there shouldn't be more type conversions through QVariant".
PS: Random side-track question: How comparable are values of type 'int'
and 'QUrl' if one applies 'common sense'? I even accept answer related
to non-0 int values only.
More information about the Development