I have a weird error when I try to compile this piece of code.
I will explain my problem.
I defined a vector2D as following:
typedef struct LX_Vector2D
{
float vx;
float vy;
LX_Vector2D& operator =(const LX_Vector2D v); // Defined
} LX_Vector2D;
I also defined two operators on this vector:
bool operator ==(LX_Vector2D& u,LX_Vector2D& v); // Are u and v equal?
LX_Vector2D operator -(LX_Vector2D& u); // Get the opposite vector
All of these overloaded operators was defined.
So I tested these operators in the following code:
LX_Vector2D u = {3.14,-2.56};
LX_Vector2D expected_vec = {-u.vx,-u.vy};
if(expected_vec == (-u)) // ERROR
cout << "OK" << endl;
else
cout << "NO" << endl;
When I compile this code, I have this error:
no match for ‘operator==’ in ‘expected_vec == operator-((* & u))‘
I have no problem with '=' and '==' because I defined and tested them before I implemented '-'.
But when I modify this code to get this:
u = -u;
if(expected_vec == u) // OK
I have no error.
I do not understand that, because it seems these two pieces of code are semantically identical.
Here is the definition of operator '-':
LX_Vector2D operator -(LX_Vector2D& u)
{
return {-u.vx,-u.vy};
}
So my question is:
Why doesn't my compiler recognize ‘expected_vec == (-u)‘ as a call of operator '==' with expected_vec and (-u) as parameters?
Another question:
How can I have the possibility to use if(expected_vec == (-u)) without any problem, if it is possible?
I use g++ 4.6.1.
The problem here is that the result from operator- when used as part of another expression is a temporary value, and that operator== takes non-constant references. A non-constant reference can't bind to a temporary value.
The simple solution? Make the operator== function take constant references:
bool operator ==(const LX_Vector2D& u, const LX_Vector2D& v)
// ^^^^^ ^^^^^
// Note the use of `const`
As a general recommendation, when declaring functions that will not modify their arguments, always pass the arguments as constant. It will avoid problems like this, and may also help the compiler with possible optimizations.
Operator - returns a temporary object:
LX_Vector2D operator -(LX_Vector2D& u)
while your comparison operator accepts a non-const reference:
bool operator ==(LX_Vector2D& u,LX_Vector2D& v)
Temporary objects, like returned by the - operator, cannot be used as non-const references. It's not allowed because there is no purpose modifying an object that is about to go out of scope anyway, so the compiler makes sure you don't even attempt it.
As a general rule, you should make any function that does not modify its arguments take const references instead, especially comparison functions:
bool operator ==(const LX_Vector2D& u,const LX_Vector2D& v)
in addition to the other answers, your assignment operator should also take a const& as in:
LX_Vector2D& operator =(const LX_Vector2D& v)
note the & after the parameter type.
As a general rule, and to avoid the construction of unnecessary copies of objects, parameters of complex types should almost always be const & if you are not planning on changing the parameter instance. Or if you are planning on changing the parameter instance, then simply as a reference, i.e., &.
Related
My assignment is having us overload the ==, <, and > operators. I understand that operator overloading essentially overrides the code of an operator. I have found a way to overload the + and - operators. My problem appears when I try to overload the == operator. Maybe I am going about this wrong, but I am trying to make a function to return a string saying that they are equal or not.
Temperature operator == (Temperature const &temp1, Temperature const &temp2)
{
int holder;
if(temp1 == temp2)
{
holder = 1;
}
return holder;
}
I also tried to return 1 so that I could make a if statement in the main function to check if their equal or not.
Temperature operator == (Temperature const &temp1, Temperature const &temp2)
{
string holder;
if(temp1 == temp2)
{
holder = "temp1 is equal to temp2";
}
return holder;
}
I know that there's not much difference between the attempts but I'm struggling to find ways to go about it.
Your operator is returning the wrong type.
It should look like this:
bool operator == (Temperature const &temp1, Temperature const &temp2)
return true if the two compare equal, false otherwise.
Your code got three problems. First, you're trying to compare two objects by calling compare operator within compare operator for those two objects (ie. calling itself). Second, you're returning an object value instead of bool. An you're returning uninitialized value when comparison failed.
It's obvious from your code, that Temperature is context-convertible from int, i.e., it's some integral type, in this case overload causes problems. You have to have an unambiguous overload.
In general, free-standing operator== for MyClass may look something like this:
bool operator == (MyClass const &a1, MyClass const &a2)
{
return (a1.value1 == a2.value1) && (a1.value2 == a2.value2);
}
It should be a friend function or have access to members of class, of course.
The point of overloading operators is to define them for particular type(s) of parameters. They are functions, just like any other overloaded function and must be distinctive from other instances of that operator. They may introduce a new behavior (example: << and >> operators of <iostream>), or just provide implied behavior. Exclusions are new\delete and type conversion operators.
I'm compiling some c++ code of a class MegaInt which is a positive decimal type class that allows arithmetic operations on huge numbers.
I want to overload operator bool to allow code like this:
MegaInt m(45646578676547676);
if(m)
cout << "YaY!" << endl;
This is what I did:
header:
class MegaInt
{
public:
...
operator bool() const;
};
const MegaInt operator+(const MegaInt & left, const MegaInt & right);
const MegaInt operator*(const MegaInt & left, const MegaInt & right);
implementation:
MegaInt::operator bool() const
{
return *this != 0;
}
const MegaInt operator+(const MegaInt & left, const MegaInt & right)
{
MegaInt ret = left;
ret += right;
return ret;
}
Now, the problem is if I do:
MegaInt(3424324234234342) + 5;
It gives me this error:
ambiguous overload for 'operator+' in 'operator+(const MegaInt&, const MegaInt&)
note: candidates are: operator+(int, int) |
note: const MegaInt operator+(const MegaInt&, const MegaInt&)|
I don't know why. How is the overloaded bool() causing operator+ to become ambiguous?¸
Thank You.
Well, everyone gave me great answers, unfortunately, none of them seem to solve my problem entirely.
Both void* or the Safe Bool Idiom works. Except for one tiny problem, I hope has a workaround:
When comparing with 0 like:
if (aMegaInt == 0)
The compiler gives an ambiguous overload error again. I understand why: it doesn't know if we're comparing to false or to MegaInt of value 0. None the less, in that case, I'd want it to cast to MegaInt(0). Is there a way to force this?
Thank You Again.
The C++ compiler is allowed to automatically convert bool into int for you, and that's what it wants to do here.
The way to solve this problem is to employ the safe bool idiom.
Technically, creating an operator void* is not an example of the safe bool idiom, but it's safe enough in practice, because the bool/int problem you're running into is a common error, and messes up some perfectly reasonable and otherwise correct code (as you see from your question), but misuses of the void* conversion are not so common.
The wikipedia entry on explicit conversion operators for C++0x has a decent summary of why you see this error pre-C++0x. Basically, the bool conversion operator is an integral conversion type, so it will be used in an integral arithmetic expression. The pre-C++0x fix is to instead use void * as the conversion operator; void * can be converted to a boolean expression, but not to an integral expression.
As Erik's answer states, the problem here is that by providing an implicit conversion to bool you are opening the door to expressions that can mean multiple things; in this case the compiler will complain of ambiguity and give your an error.
However, note that providing an implicit conversion to void* will not let you off the hook; it will just change the set of expressions which present a problem.
There are two airtight solutions to this issue:
Make the conversion to bool explicit (which can be undesirable if the class represents an entity with an intuitive "true/false" value)
Use the safe bool idiom (this really covers all bases, but as many good things in life and C++ is way too complicated -- you pay the price)
The problem is that bool can freely convert to int. So the expression MegaInt(3424324234234342) + 5; can equally validly be interpreted this way:
(bool)(MegaInt(3424324234234342)) + 5;
or:
MegaInt(3424324234234342) + MegaInt(5);
Each one of those expressions involves one user defined conversion and are equal in the eyes of the compiler. Conversion to bool is highly problematic for this reason. It would be really nice to have a way to say it should only happen in a context that explicitly requires a bool, but there isn't. :-/
The conversion to void * that someone else suggests is a workaround, but I think as a workaround it has problems of its own and I wouldn't do it.
MegaInt(3424324234234342) + 5;
MegaInt + int;
Should the compiler convert your MegaInt to an integral (bool is an integral type) or the integer to MegaInt (you have an int constructor)?
You fix this by creating an operator void * instead of an operator bool:
operator void *() const { return (*this != 0) ? ((void *) 1) : ((void *) 0); }
Others have mentioned the Safe Bool Idiom. However, for objects like yours it is a bad idea to add all this nasty, special logic when you want full algebra support anyway.
You're defining a custom integer type. You get far more for your effort by defining "operator==" and "operator!=", then implementing "operator bool()" as something like:
operator bool()
{
return (*this != 0);
}
Just from those 3 functions you get all of the "if" idioms for integers, and they'll behave the same for your custom ints as the built-in ones: "if(a==b)", "if(a!=b)", "if(a)", "if(!a)". Your implicit "bool" rule will also (if you're careful) work intuitively as well.
Besides, the full "Safe Bool Idiom" is unnecessary. Think about it- the only time you need it is "1) comparison of 2 objects is ill-defined or undefined, 2) cast to (int) or other primitive types needs to be protected and 3) object validity IS well-defined (the actual source of the returned bool)."
Well, 2) is only a consideration if you actually wish to SUPPORT casting to a numeric type like int or float. But for objects that have NO well-defined notion of equality (# 1), providing such casts unavoidably creates the risk of the very "if(a==b)" logic bombs the idiom supposedly protects you from. Just declare "operator int()" and such private like you do with the copy ctor on non-copyable objects and be done with it:
class MyClass {
private:
MyClass(const MyClass&);
operator int();
operator long();
// float(), double(), etc. ...
public:
// ctor & dtor ..
bool operator==(const MyClass& other) const { //check for equality logic... }
bool operator!=(const MyClass& other) const { return !(*this == other); }
operator bool() { return (*this != 0); }
};
The copy assignment operator has the usual signature:
my_class & operator = (my_class const & rhs);
Does the following signature have any practical use?
my_class const & operator = (my_class const & rhs);
You can only define one or the other, but not both.
The principle reason to make the return type of copy-assignment a non-const reference is that it is a requirement for "Assignable" in the standard.
If you make the return type a const reference then your class won't meet the requirements for use in any of the standard library containers.
Don't do that. It prevent a client from writing something like:
(a = b).non_const_method();
instead of the longer form:
a = b;
a.non_const_method();
While you may not like the shorthand style, it's really up to the user of the library to decide how they want to write the code.
An answer that mirrors one from Overloading assignment operator in C++:
Returning a const& will still allow assignment chaining:
a = b = c;
But will disallow some of the more unusual uses:
(a = b) = c;
Note that this makes the assignment operator have semantics similar to what it has in C, where the value returned by the = operator is not an lvalue. In C++, the standard changed it so the = operator returns the type of the left operand, so the result is an lvalue. But as Steve Jessop noted in a comment to another answer, while that makes it so the compiler will accept
(a = b) = c;
even for built-ins, the result is undefined behavior for built-ins since a is modified twice with no intervening sequence point. That problem is avoided for non-builtins with an operator=() because the operator=() function call serves as a sequence point.
I see no problem returning a const& unless you want to specifically allow the lvalue semantics (and design the class to ensure it acts sensibly with those semantics). If you're users want to do something unusual with the result of operator=(), I'd prefer that the class disallow it rather than hope it gets it right by chance instead of design.
Also. note that while you said:
You can only define one or the other, but not both.
that's because the function signature in C++ doesn't take into account the return value type. You could however have multiple operator=() assignement operatiors that take different parameters and return different types appropriate to the parameter types:
my_class& operator=( my_class& rhs);
my_class const& operator=(my_class const& rhs);
I'm not entirely sure what this would buy you though. The object being assigned to (that is presumably the reference being returned) is non-const in both cases, so there's no logical reason to return a const& just because the righ-hand-side of the = is const. But maybe I'm missing something...
Effective C++ explains that this would break compatibility with the built-in types of C++.
You can do this with plain ints:
(x = y) = z;
so he reasons, however silly this looks like, one should be able to do the same with one's own type as well.
This example is there in 2nd Edition, although not anymore in the 3rd. However, this quote from 3rd Ed., Item 10 tells the same still:
[...] assignment returns a reference to its left-hand argument, and that's the convention you should follow when you implement assignment operators for your classes:
class Widget {
public:
...
Widget& operator=(const Widget& rhs) // return type is a reference to
{ // the current class
...
return *this; // return the left-hand object
}
...
};
Why is everyone obsessing over (a = b) = c? Has that ever been written by accident?
There is probably some unforeseen utility of the result of assignment being altered. You don't just make arbitrary rules against made-up examples that look funny. Semantically there is no reason that it should be const, so do not declare it const for lexical side effects.
Here is an example of somewhat reasonable code that breaks for const & assignment:
my_class &ref = a = b;
As in any other usage of const, const is the default, unless you really want to let the user change.
Yes, it should be const. Otherwise clients can do this:
class MyClass
{
public:
MyClass & operator = (MyClass const & rhs);
}
void Foo() {
MyClass a, b, c;
(a = b) = c; //Yikes!
}
I realize this is a basic question but I have searched online, been to cplusplus.com, read through my book, and I can't seem to grasp the concept of overloaded operators. A specific example from cplusplus.com is:
// vectors: overloading operators example
#include <iostream>
using namespace std;
class CVector {
public:
int x,y;
CVector () {};
CVector (int,int);
CVector operator + (CVector);
};
CVector::CVector (int a, int b) {
x = a;
y = b;
}
CVector CVector::operator+ (CVector param) {
CVector temp;
temp.x = x + param.x;
temp.y = y + param.y;
return (temp);
}
int main () {
CVector a (3,1);
CVector b (1,2);
CVector c;
c = a + b;
cout << c.x << "," << c.y;
return 0;
}
From http://www.cplusplus.com/doc/tutorial/classes2/ but reading through it I'm still not understanding them at all. I just need a basic example of the point of the overloaded operator (which I assume is the "CVector CVector::operator+ (CVector param)").
There's also this example from wikipedia:
Time operator+(const Time& lhs, const Time& rhs)
{
Time temp = lhs;
temp.seconds += rhs.seconds;
if (temp.seconds >= 60)
{
temp.seconds -= 60;
temp.minutes++;
}
temp.minutes += rhs.minutes;
if (temp.minutes >= 60)
{
temp.minutes -= 60;
temp.hours++;
}
temp.hours += rhs.hours;
return temp;
}
From "http://en.wikipedia.org/wiki/Operator_overloading"
The current assignment I'm working on I need to overload a ++ and a -- operator.
Thanks in advance for the information and sorry about the somewhat vague question, unfortunately I'm just not sure on it at all.
Operator overloading is the technique that C++ provides to let you define how the operators in the language can be applied to non-built in objects.
In you example for the Time class operator overload for the + operator:
Time operator+(const Time& lhs, const Time& rhs);
With that overload, you can now perform addition operations on Time objects in a 'natural' fashion:
Time t1 = some_time_initializer;
Time t2 = some_other_time_initializer;
Time t3 = t1 + t2; // calls operator+( t1, t2)
The overload for an operator is just a function with the special name "operator" followed by the symbol for the operator being overloaded. Most operators can be overloaded - ones that cannot are:
. .* :: and ?:
You can call the function directly by name, but usually don't (the point of operator overloading is to be able to use the operators normally).
The overloaded function that gets called is determined by normal overload resolution on the arguments to the operator - that's how the compiler knows to call the operator+() that uses the Time argument types from the example above.
One additional thing to be aware of when overloading the ++ and -- increment and decrement operators is that there are two versions of each - the prefix and the postfix forms. The postfix version of these operators takes an extra int parameter (which is passed 0 and has no purpose other than to differentiate between the two types of operator). The C++ standard has the following examples:
class X {
public:
X& operator++(); //prefix ++a
X operator++(int); //postfix a++
};
class Y { };
Y& operator++(Y&); //prefix ++b
Y operator++(Y&, int); //postfix b++
You should also be aware that the overloaded operators do not have to perform operations that are similar to the built in operators - being more or less normal functions they can do whatever you want. For example, the standard library's IO stream interface uses the shift operators for output and input to/from streams - which is really nothing like bit shifting. However, if you try to be too fancy with your operator overloads, you'll cause much confusion for people who try to follow your code (maybe even you when you look at your code later).
Use operator overloading with care.
An operator in C++ is just a function with a special name. So instead of saying Add(int,int) you say operator +(int,int).
Now as any other function, you can overload it to say work on other types. In your vector example, if you overload operator + to take CVector arguments (ie. operator +(CVector, CVector)), you can then say:
CVector a,b,res;
res=a+b;
Since ++ and -- are unary (they take only one argument), to overload them you'd do like:
type operator ++(type p)
{
type res;
res.value++;
return res;
}
Where type is any type that has a field called value. You get the idea.
What you found in those references are not bad examples of when you'd want operator overloading (giving meaning to vector addition, for example), but they're horrible code when it comes down to the details.
For example, this is much more realistic, showing delegating to the compound assignment operator and proper marking of a const member function:
class Vector2
{
double m_x, m_y;
public:
Vector2(double x, double y) : m_x(x), m_y(y) {}
// Vector2(const Vector2& other) = default;
// Vector2& operator=(const Vector2& other) = default;
Vector2& operator+=(const Vector2& addend) { m_x += addend.m_x; m_y += addend.m_y; return *this; }
Vector2 operator+(const Vector2& addend) const { Vector2 sum(*this); return sum += addend; }
};
From your comments above, you dont see the point of all this operator overloading?
Operator overloading is simply 'syntactic sugar' hiding a method call, and making code somehwhat clearer in many cases.
Consider a simple Integer class wrapping an int. You would write add and other arithmetic methods, possibly increment and decrement as well, requiring a method call such as my_int.add(5). now renaming the add method to operator+ allows my_int + 5, which is more intuitive and clearer, cleaner code. But all it is really doing is hiding a call to your operator+ (renamed add?) method.
Things do get a bit more complex though, as operator + for numbers is well understood by everyone above 2nd grade. But as in the string example above, operators should usually only be applied where they have an intuitive meaning. The Apples example is a good example of where NOT to overload operators.
But applied to say, a List class, something like myList + anObject, should be intuitively understood as 'add anObject to myList', hence the use of the + operator. And operator '-' as meaning 'Removal from the list'.
As I said above, the point of all this is to make code (hopefully) clearer, as in the List example, which would you rather code? (and which do you find easier to read?) myList.add( anObject ) or myList + onObject? But in the background, a method (your implementation of operator+, or add) is being called either way. You can almost think of the compiler rewritting the code: my_int + 5 would become my_int.operator+(5)
All the examples given, such as Time and Vector classes, all have intuitive definitions for the operators. Vector addition... again, easier to code (and read) v1 = v2 + v3 than v1 = v2.add(v3). This is where all the caution you are likely to read regarding not going overboard with operators in your classes, because for most they just wont make sense. But of course there is nothing stopping you putting an operator & into a class like Apple, just dont expect others to know what it does without seeing the code for it!
'Overloading' the operator simply means your are supplying the compiler with another definition for that operator, applied to instances of your class. Rather like overloading methods, same name... different parameters...
Hope this helps...
The "operator" in this case is the + symbol.
The idea here is that an operator does something. An overloaded operator does something different.
So, in this case, the '+' operator, normally used to add two numbers, is being "overloaded" to allow for adding vectors or time.
EDIT: Adding two integers is built-in to c++; the compiler automatically understands what you mean when you do
int x, y = 2, z = 2;
x = y + z;
Objects, on the other hand, can be anything, so using a '+' between two objects doesn't inherently make any sense. If you have something like
Apple apple1, apple2, apple3;
apple3 = apple1 + apple2;
What does it mean when you add two Apple objects together? Nothing, until you overload the '+' operator and tell the compiler what it is that you mean when you add two Apple objects together.
An overloaded operator is when you use an operator to work with types that C++ doesn't "natively" support for that operator.
For example, you can typically use the binary "+" operator to add numeric values (floats, ints, doubles, etc.). You can also add an integer type to a pointer - for instance:
char foo[] = "A few words";
char *p = &(foo[3]); // Points to "e"
char *q = foo + 3; // Also points to "e"
But that's it! You can't do any more natively with a binary "+" operator.
However, operator overloading lets you do things the designers of C++ didn't build into the language - like use the + operator to concatenate strings - for instance:
std::string a("A short"), b(" string.");
std::string c = a + b; // c is "A short string."
Once you wrap your head around that, the Wikipedia examples will make more sense.
A operator would be "+", "-" or "+=". These perform different methods on existing objects. This in fact comes down to a method call. Other than normal method calls these look much more natural to a human user. Writing "1 + 2" just looks more normal and is shorter than "add(1,2)". If you overload an operator, you change the method it executes.
In your first example, the "+" operator's method is overloaded, so that you can use it for vector-addition.
I would suggest that you copy the first example into an editor and play a little around with it. Once you understand what the code does, my suggestion would be to implement vector subtraction and multiplication.
Before starting out, there are many operators out there! Here is a list of all C++ operators: list.
With this being said, operator overloading in C++ is a way to make a certain operator behave in a particular way for an object.
For example, if you use the increment/decrement operators (++ and --) on an object, the compiler will not understand what needs to be incremented/decremented in the object because it is not a primitive type (int, char, float...). You must define the appropriate behavior for the compiler to understand what you mean. Operator overloading basically tells the compiler what must be accomplished when the increment/decrement operators are used with the object.
Also, you must pay attention to the fact that there is postfix incrementing/decrementing and prefix incrementing/decrementing which becomes very important with the notion of iterators and you should note that the syntax for overloading these two type of operators is different from each other. Here is how you can overload these operators: Overloading the increment and decrement operators
The accepted answer by Michael Burr is quite good in explaining the technique, but from the comments it seems that besides the 'how' you are interested in the 'why'. The main reasons to provide operator overloads for a given type are improving readability and providing a required interface.
If you have a type for which there is a single commonly understood meaning for an operator in the domain of your problem, then providing that as an operator overload makes code more readable:
std::complex<double> a(1,2), b(3,4), c( 5, 6 );
std::complex<double> d = a + b + c; // compare to d = a.add(b).add(c);
std::complex<double> e = (a + d) + (b + c); // e = a.add(d).add( b.add(c) );
If your type has a given property that will naturally be expressed with an operator, you can overload that particular operator for your type. Consider for example, that you want to compare your objects for equality. Providing operator== (and operator!=) can give you a simple readable way of doing so. This has the advantage of fulfilling a common interface that can be used with algorithms that depend on equality:
struct type {
type( int x ) : value(x) {}
int value;
};
bool operator==( type const & lhs, type const & rhs )
{ return lhs.value == rhs.value; }
bool operator!=( type const & lhs, type const & rhs )
{ return !lhs == rhs; }
std::vector<type> getObjects(); // creates and fills a vector
int main() {
std::vector<type> objects = getObjects();
type t( 5 );
std::find( objects.begin(), objects.end(), t );
}
Note that when the find algorithm is implemented, it depends on == being defined. The implementation of find will work with primitive types as well as with any user defined type that has an equality operator defined. There is a common single interface that makes sense. Compare that with the Java version, where comparison of object types must be performed through the .equals member function, while comparing primitive types can be done with ==. By allowing you to overload the operators you can work with user defined types in the same way that you can with primitive types.
The same goes for ordering. If there is a well defined (partial) order in the domain of your class, then providing operator< is a simple way of implementing that order. Code will be readable, and your type will be usable in all situations where a partial order is required, as inside associative containers:
bool operator<( type const & lhs, type const & rhs )
{
return lhs < rhs;
}
std::map<type, int> m; // m will use the natural `operator<` order
A common pitfall when operator overloading was introduced into the language is that of the 'golden hammer' Once you have a golden hammer everything looks like a nail, and operator overloading has been abused.
It is important to note that the reason for overloading in the first place is improving readability. Readability is only improved if when a programmer looks at the code, the intentions of each operation are clear at first glance, without having to read the definitions. When you see that two complex numbers are being added like a + b you know what the code is doing. If the definition of the operator is not natural (you decide to implement it as adding only the real part of it) then code will become harder to read than if you had provided a (member) function. If the meaning of the operation is not well defined for your type the same happens:
MyVector a, b;
MyVector c = a + b;
What is c? Is it a vector where each element i is the sum of of the respective elements from a and b, or is it a vector created by concatenating the elements of a before the elements of b. To understand the code, you would need to go to the definition of the operation, and that means that overloading the operator is less readable than providing a function:
MyVector c = append( a, b );
The set of operators that can be overloaded is not restricted to the arithmetic and relational operators. You can overload operator[] to index into a type, or operator() to create a callable object that can be used as a function (these are called functors) or that will simplify usage of the class:
class vector {
public:
int operator[]( int );
};
vector v;
std::cout << v[0] << std::endl;
class matrix {
public:
int operator()( int row, int column );
// operator[] cannot be overloaded with more than 1 argument
};
matrix m;
std::cout << m( 3,4 ) << std::endl;
There are other uses of operator overloading. In particular operator, can be overloaded in really fancy ways for metaprogramming purposes, but that is probably much more complex than what you really care for now.
Another use of operator overloading, AFAIK unique to C++, is the ability to overload the assignment operator. If you have:
class CVector
{
// ...
private:
size_t capacity;
size_t length;
double* data;
};
void func()
{
CVector a, b;
// ...
a = b;
}
Then a.data and b.data will point to the same location, and if you modify a, you affect b as well. That's probably not what you want. But you can write:
CVector& CVector::operator=(const CVector& rhs)
{
delete[] data;
capacity = length = rhs.length;
data = new double[length];
memcpy(data, rhs.data, length * sizeof(double));
return (*this);
}
and get a deep copy.
Operator overloading allows you to give own meaning to the operator.
For example, consider the following code snippet:
char* str1 = "String1";
char* str2 = "String2";
char str3[20];
str3 = str1 + str2;
You can overload the "+" operator to concatenate two strings. Doesn't this look more programmer-friendly?
Is there a canonical or recommended pattern for implementing arithmetic operator overloading in C++ number-like classes?
From the C++ FAQ, we have an exception-safe assignment operator that avoids most problems:
class NumberImpl;
class Number {
NumberImpl *Impl;
...
};
Number& Number::operator=(const Number &rhs)
{
NumberImpl* tmp = new NumberImpl(*rhs.Impl);
delete Impl;
Impl = tmp;
return *this;
}
But for other operators (+, +=, etc..) very little advice is given other than to make them behave like the operators on built-in types.
Is there a standard way of defining these? This is what I've come up with - are there pitfalls I'm not seeing?
// Member operator
Number& Number::operator+= (const Number &rhs)
{
Impl->Value += rhs.Impl->Value; // Obviously this is more complicated
return *this;
}
// Non-member non-friend addition operator
Number operator+(Number lhs, const Number &rhs)
{
return lhs += rhs;
}
In Bjarne Stroustrup's book "The C++ Programming Language", in chapter 11 (the one devoted to Operator Overloading) he goes through witting a class for a complex number type (section 11.3).
One thing I do notice from that section is that he implements mixed type operations... this is probably expected for any numeric class.
In general, what you've got looks good.
The big thing to consider when writing any operator is that member operators do not undergo conversions on the left parameter:
struct example {
example(int);
example operator + (example);
};
void foo() {
example e(3), f(6);
e + 4; // okay: right operand is implicitly converted to example
e + f; // okay: no conversions needed.
6 + e; // BAD: no matching call.
}
This is because conversion never applies to this for member functions, and this extends to operators. If the operator was instead example operator + (example, example) in the global namespace, it would compile (or if pass-by-const-ref was used).
As a result, symmetric operators like + and - are generally implemented as non-members, whereas the compound assignment operators like += and -= are implemented as members (they also change data, meaning they should be members). And, since you want to avoid code duplication, the symmetric operators can be implemented in terms of the compound assignment ones (as in your code example, although convention recommends making the temporary inside the function).
The convention is to write operator+(const T&) and operator-(const T&) in terms of operator+=(const T&) and operator-=(const T&). If it makes sense to add and subtract to/from primitive types then you should write a constructor that constructs the object from the primitive type. Then the overloaded operators will also work for primitive types, because the compiler will call the appropriate constructor implicitly.
As you mentioned yourself, you should avoid giving access privileges to functions that don't need it. But in your code above for operator+(Number, const Number&) I'd personally make both parameters const references and use a temp. I think it isn't surprising the commenter below your question missed this; unless you have a good reason not to, avoid surprises and tricks and be as obvious as possible.
If you want your code to integrate with other numeric types, say std::complex, watch out for cyclic conversions. That is, don't supply operator OtherNumeric() in Numeric if OtherNumeric supplies a constructor that takes a Numeric parameter.
It is traditional to write the operator X in terms of the operator =X
It is also traditional the all parameters to the standard operators are const
// Member operator
// This was OK
Number& Number::operator+= (Number const& rhs)
{
Impl->Value += rhs.Impl->Value; // Obviously this is more complicated
return *this;
}
// Non-member non-friend addition operator
Number operator+(Number const& lhs,Number const& rhs)
{
// This I would set the lhs side to const.
// Make a copy into result.
// Then use += add the rhs
Number result(lhs);
return result += rhs;
}
You mention assignment operator.
But you did not mention the copy constructor. Since your class has ownership of a RAW pointer I would expect you to define this as well. The Assignment operator is then traditionally written in terms of the copy constructor.