[Development] Converting types in Qt

André Pönitz 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.
> Example:
> 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 mailing list