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) constructor. 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". Andre' 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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
