Abstract
In this chapter, you’ll learn how to add support for operators such as add and subtract to your classes so that they can be applied to objects. This will make the types that you define behave more like fundamental data types and offer a more natural way to express some of the operations between objects. You’ve already seen how classes can have member functions that operate on the member variables of an object. Operator overloading enables you to write member functions that enable the basic operators to be applied to class objects.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Prior to C++17, it was not even guaranteed that the left operand of an overloaded && or || operator would be evaluated before the right operand like it is for the built-in operators. That is, the compiler was allowed to evaluate the right operand before it even started evaluating the left operand. This would have made for another potential source of subtle bugs. This was also the reason that prior to C++17 overloading the comma operator (,) was generally discouraged.
- 2.
In actuality, the compiler will not use the named comparison functions std::is_lteq() or std::is_gteq(). These are just meant for us, mere humans, to make our code readable. But the generated code will of course be equivalent.
- 3.
Consider the == and != operators of std::string. Now suppose you are comparing the strings “Little Lily Lovelace likes licking luscious lemon lollipops” and “Little Lily Lovelace likes lasagna”. Simply by comparing their length, operators == and != can then instantly determine that these two strings cannot possibly be equal. Operator <=>, however, has to work harder: to order these two strings it has to compare at least 29 characters. Unlike == and !=, the <=> operator cannot stop after comparing the lengths of the strings. “lasagna” comes before “licking luscious lemon lollipops”, naturally, but not because it’s a shorter string. This illustrates why rewriting == and != expressions in terms of <=> may lead to suboptimal performance.
- 4.
Defaulted != and <, >, <=, or >= operators are evaluated in terms of == and <=>, respectively, as always. The only reason you would ever define or default these operators in C++20 is to allow taking the address of these functions. In practice, however, you mostly use function objects in C++ (see Chapter 19), and there’s scarcely ever a need to work with function pointers.
- 5.
In practice you will often not care precisely how your objects are ordered—as long as they are ordered in an efficient and consistent way. A defaulted <=> operator is then typically perfectly adequate. If the goal is simply to sort a collection of Box objects for more efficient processing, for instance, or to use them as keys for ordered associative containers (see Chapter 20), then you really do not care whether Boxes are sorted lexicographically or by volume. In fact, for performance reasons, the stronger lexicographical order might then even be preferred over the weaker volume-based order!
- 6.
Yes, C programmers do seem to like abbreviated function names. Other beauties from the same <cstring> header are strspn(), strpbrk(), strrchr(), and strstr(). For obvious reasons, we categorically advise against this practice: code is not meant to be compact, it’s meant to be readable!
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2020 Ivor Horton and Peter Van Weert
About this chapter
Cite this chapter
Horton, I., Van Weert, P. (2020). Operator Overloading. In: Beginning C++20. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5884-2_13
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5884-2_13
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-5883-5
Online ISBN: 978-1-4842-5884-2
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)