There are ten rules for overloading and overload operators in the C++ core guidelines. Many of them are pretty obvious, but your software may become very unintuitive if you don’t follow them.
I’m pretty surprised to have only ten rules for overloading in the guidelines. I’m particularly surprised because I had a lot of discussions in the past about the overloading of operators in C++. Additionally, at least MISRA C++, which is heavily used in the automotive and embedded area, forbids operator overloading.
In contrast to the discussion in C++, I have not a discussion in Python about operator overloading in mind, but Python is heavily based on operator overloading. To get an idea. Look at the following special functions starting and ending with two underscores, lovingly called dunder in Python. You must implement them to get a type that behaves like an int.
But let me continue with C++. Here are the ten rules.
- C.160: Define operators primarily to mimic conventional usage
- C.161: Use nonmember functions for symmetric operators
- C.162: Overload operations that are roughly equivalent
- C.163: Overload only for operations that are roughly equivalent
- C.164: Avoid conversion operators
- C.165: Use
usingfor customization points
- C.166: Overload unary
&only as part of a system of smart pointers and references
- C.167: Use an operator for an operation with its conventional meaning
- C.168: Define overloaded operators in the namespace of their operands
- C.170: If you feel like overloading a lambda, use a generic lambda
A lot of the rules are quite obvious; therefore, I often can make it short.
Overloading and overloaded operators
This was obvious. Right? The following rule sounds easy, but the discussion of it is pretty enlighting.
Implementing a symmetric operator such as + is impossible inside the class.
Assume that you want to implement a type MyInt. MyInt should support addition with MyInt‘s and built-in int‘s. Let’s give it a try.
Because of the implicit conversion constructor (1), expression (2) is valid. In contrast, the last expression (3) is invalid because the 5 in the expression 5 + myFive will not implicitly convert to a MyInt; therefore, I got a compiler error.
Trying to compile the program will fail because int does not have an overloaded + operator for MyInt.
The minor program has a lot of issues:
- The + operator is not symmetric.
- The val variable is public.
- The conversion constructor is implicit.
It’s pretty easy to overcome the first issues with a non-member operator + that is in the class declared as a friend.
Now, implicit conversion from int to MyInt kicks in, and the variable val is private. According to rule C.164: Avoid conversion operators, you should not use an implicit conversion constructor. By making the conversion constructor in the following example explicit, the example will break.
Thanks to the explicit conversion operator, implicit conversion from int to MyInt will not happen; therefore, lines (2) and (3) fail.
At least I followed the rule, and my operator is symmetric.
One obvious way to solve the original challenge is to implement two additional + operators for MyInt4. One should take an int as left, and one should take an int as correct argument.
C.162: Overload operations that are roughly equivalent, and C.163: Overload only for operations that are roughly equivalent
This time, I can make it short. Equivalent operations should have the same name. Or the other way around. Non-equivalent operations should not have the same name.
Here is an example from the guidelines:
Invoking print(arg) with an argument feels like generic programming. You do not have to care which version of print will be used.
This will not hold for the three following functions because they have different names:
If non-equivalent operations have the same name, the names may be too general or wrong. This is confusing and error-prone.
The following rule is quite essential: C.164: Avoid conversion operators. I already mentioned it in rule C.161. You should not use an implicit conversion constructor and – this is new – an implicit conversion operator. Why? I will write about it in the next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,