I've been trying to get smart on operator overloading, but it seems that various sources disagree on how some operators should be overloaded.
A book I'm using, for example, says to overload the addition operator with a function that uses only one parameter, while an online resource says to create one with two.
Before I get into any specific questions, does someone here have a reference source for this information? I'd like it to be simple and clear, not so much like the stuff that the committees put out.
If a binary operator is written as class member, one argument is implicit ( this, pointing to the object itself ). The other argument must be provided explicitly.
If the operator is defined as external function, you have to provide both arguments.
eg:
1 2 3 4 5 6
class C
{
C operator+ ( const C& other ) const; // member operator +
};
C operator+ ( const C& a, const C& b ); // external operator+
In general, I would say use the class method option if possible. But there are some cases where you would need to (say, you want to overload operator+() for when your class is the second parameter of the operator.
Also, there is a difference between the order of arguments. You must usually provide both a member (or non-member, at your option) version and also a non-member friend.
Looks fine, though your operator+() and operator*() should be const.
Well, something's not working. I'll take a closer look. Of course, it's not helping that the Eclipse debugger is giving me odd results, too. (I love learning multiple things at once.)
I always screw up the positioning of the const tag; should it go at the start of the line?
Thanks, firedraco. So...I assume this is a good thing for a constructor.
Any idea why my compier doesn't like it? I get this message:
/Users/mzimmers/wideband/SoC simulator/modem_simulator/headers/SocReg.h:25: error: declaration of 'operator+' as non-function
/Users/mzimmers/wideband/SoC simulator/modem_simulator/headers/SocReg.h:25: error: expected ';' before 'const'
Don't make binary arithmetic operators members, because then the first argument will not participate in "standard conversions". In other words, if you have conversion from int to your user type, and someone does <some int> + <some user type object>, the first argument wont get converted. This is the way the cookie crumbles for member functions in general. The object for the call is of the exact type, it is never converted. If you use friend functions, then the first operand will be converted as would be probably expected. Notice that the second operand will be converted in both cases.
For unary operators you may opt to use member functions, firs because the conversions are not usually desirable then, and second because you may decide to use polymorphism for some reason.
Actually I misquoted. User type conversions are not standard conversions, but what I meant is implicit conversions. Still, here is the practical effect:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
struct S
{
S(int value = 0) : value_(value) {}
S operator + (const S& other) const
{
return S(value_ + other.value_);
}
int value_;
};
int main()
{
S a(1);
S b = a + 2; //This will work, because 2 will be converted to S(2)
S c = 2 + a; //This will not work, because operator + is member and 2 is not converted
}
Everything will work fine if you define the operator like this: