Regarding Qt's documentation on operators and related non-members

[hackerNovitiate]

Two (maybe five) questions have been bugging at me:
1. Why doesn't the Qt documentation contain copy constructors and assignment operators for certain "value-based" classes like QDate, QTime, QChar and QPoint? How come QDateTime does? Should I avoid writing "QDate newDate = otherDate"?

2. What are "Related non-members" and where do they belong, if not in the classes they're documented under?

[wysota]

1. Why doesn't the Qt documentation contain copy constructors and assignment operators for certain "value-based" classes like QDate, QTime, QChar and QPoint? How come QDateTime does? Should I avoid writing "QDate newDate = otherDate"?
Every class has those (regardless if they are hand written or provided by the compiler) so why document that and clutter the view? Same goes with destructors.


2. What are "Related non-members" and where do they belong, if not in the classes they're documented under?
They are exactly that - entities (like functions or macros) that are not members of the class but semantically belong to the class (e.g. qHash() implementations for QHash class).

[franz]

Two (maybe five) questions have been bugging at me:
1. Why doesn't the Qt documentation contain copy constructors and assignment operators for certain "value-based" classes like QDate, QTime, QChar and QPoint? How come QDateTime does? Should I avoid writing "QDate newDate = otherDate"?
The copy operator is implicit. QDate for example has only one data member: uint jd; i.e. julian date as an unsigned int. It's faster (and easier) to copy that than to (im|ex)plicitly share the thing.


2. What are "Related non-members" and where do they belong, if not in the classes they're documented under?They could theoretically also be related to something else. In case of QString:
bool operator!= ( const char * s1, const QString & s2 )
const QString operator+ ( const QString & s1, const QString & s2 )
const QString operator+ ( const QString & s1, const char * s2 )
const QString operator+ ( const char * s1, const QString & s2 )
const QString operator+ ( char ch, const QString & s )
const QString operator+ ( const QString & s, char ch )
bool operator< ( const char * s1, const QString & s2 )
QDataStream & operator<< ( QDataStream & stream, const QString & string )
bool operator<= ( const char * s1, const QString & s2 )
bool operator== ( const char * s1, const QString & s2 )
bool operator> ( const char * s1, const QString & s2 )
bool operator>= ( const char * s1, const QString & s2 )
QDataStream & operator>> ( QDataStream & stream, QString & string )
Some of these operators would be impossible to create when defining them as member (operator!=(const char *, QString) for example).

[hackerNovitiate]

Thanks guys; after your explanations and some digging around the Qt source code, things make a lot more sense. :)


Every class has those (regardless if they are hand written or provided by the compiler) so why document that and clutter the view? Same goes with destructors. Some classes had them documented whilst others didn't; I got confused by this. I thought that if a function isn't documented, it must be either unavailable, or not meant for public use. I didn't realize the documentation also reflects the implementation.

Now to the next level: I'm very curious as to why QPoint (which has 2 ints as data members) uses a non-member comparator while QLine (which has 2 QPoints as data members) uses a member comparator?



// For QPoint (a friend function)
inline bool operator==(const QPoint &p1, const QPoint &p2)
{ return p1.xp == p2.xp && p1.yp == p2.yp; }

// For QLine (a member function)
inline bool QLine::operator==(const QLine &d) const
{ return pt1 == d.pt1 && pt2 == d.pt2; }


Unlike franz's QString example, I'd imagine things would still work if they were both members (or both non-members), right? Does the current implementation provide any particular benefits?