[Development] operators as members or not

Olivier Goffart olivier at woboq.com
Thu Aug 15 09:40:44 CEST 2013

On Thursday 15 August 2013 03:11:20 Glen Mabey wrote:
> Hello,
> I'm working on a couple of new classes and I wonder whether there is a
> policy (written or otherwise) on whether operators should be members or
> not.
> In particular, this question has come up in
>   https://codereview.qt-project.org/#change,59605
> and
>   https://codereview.qt-project.org/#change,60792
> I am no C++ philosopher, but I understand that some authorities (like
> stackoverflow) have their reasons for asserting that operators should not
> be members -- they also cite some sources.
> http://stackoverflow.com/questions/4421706/operator-overloading/4421729#442
> 1729
> Looks like Oliver Goffart did also weigh in on the issue, in 60792.
> Is it possible that the Coding Conventions could be amended to indicate
> which way this issue should go, if only for new classes?

The stack overflow answer says it well:

Binary operator that treat both their member equaly should not be member.
Because, in addition to the other reason mentioned in the stack overflow 
answer, the member are not equals when the operator is a member.

Example with QLineF which unforortunatelly has its operator== as a member:

 QLineF  lineF;  QLine lineN;

 if (lineF == lineN) //Ok,  lineN is implicitly converted to QLineF
 if (lineN == lineF) //Error: QLineF cannot be converted implicitly to QLine,
                           // and the LHS is a member so no conversion applies

If the operator== was outside of the class, conversion rules would applies 
equaly for both sides.

Some Qt classes have their operator as a member, but it is a mistake that we 
cannot fix without breaking binary compatibility. But new operator should be 
outside of the class.

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

More information about the Development mailing list