4 replies to this topic

[vernonglenn]

Hello all,

So I'm trying to learn programming on my own and I'm sort of stuck on overloading increment operators. I don't understand how the compiler can distinguish between which member function to use in the given example (from a book I'm reading):

Quote

#include <iostream>
using namespace std;
#include <string>
typedef unsigned short USHORT;
class Counter
{
public:
Counter();
~Counter(){}
USHORT GetItsVal()const { return itsVal; }
void SetItsVal(USHORT x) {itsVal = x; }
//const Counter& operator++ (); // prefix
const Counter operator++ (int); // postfix
private:
USHORT itsVal;
};

Counter::Counter():
itsVal(0)
{}
/*
const Counter& Counter::operator++()
{
++itsVal;
return *this;
}
*/
const Counter Counter::operator++(int)
{
Counter temp(*this);
++itsVal;
return temp;
}


int main() {
Counter i;
cout << "The value of i is " << i.GetItsVal() << endl;
i++;
cout << "The value of i is " << i.GetItsVal() << endl;
++i;
cout << "The value of i is " << i.GetItsVal() << endl;
Counter a = ++i;
cout << "The value of a: " << a.GetItsVal();
cout << " and i: " << i.GetItsVal() << endl;
a = i++;
cout << "The value of a: " << a.GetItsVal();
cout << " and i: " << i.GetItsVal() << endl;
system("PAUSE");
return 0;
}

I would understand if instead of "a = i++;" the line read "a = i++(1);" , that way it shows explicitly it's a call to the function that takes a parameter, but the above code works just fine in visual c++. I suppose it could be the return type, but I thought you couldn't overload functions by return type


Thanks in advance

[Reedbeta]

It's a hack. The int parameter to the postfix version doesn't actually do anything useful. It's just a hacky syntax the C++ architects chose to create a distinction between the two versions of operator++, so you could overload both of them. Probably the parameter's value is always zero, or something.

They could have done something different, like introducing a new 'postfix' keyword and letting you write 'operator++() postfix' or something like that. But adding new keywords to an existing language is fraught with peril because it can break existing programs that had the bad fortune to be using that keyword as a variable name or something. So they added as few as they could get away with.

A similar thing happened with pure virtual functions, where you write '= 0' on the end of the function prototype to signify it's pure virtual. Again, they could have chosen to add a 'pure' keyword or suchlike, but the C++ decision-makers are very averse to new keywords.

[vernonglenn]

Thanks.So I'm assuming this is also true for postfix operator--?

[Reedbeta]

Yep.

[.oisyn]

Reedbeta, on 03 August 2012 - 12:01 AM, said:

They could have done something different, like introducing a new 'postfix' keyword and letting you write 'operator++() postfix' or something like that. But adding new keywords to an existing language is fraught with peril because it can break existing programs that had the bad fortune to be using that keyword as a variable name or something. So they added as few as they could get away with.

A similar thing happened with pure virtual functions, where you write '= 0' on the end of the function prototype to signify it's pure virtual. Again, they could have chosen to add a 'pure' keyword or suchlike, but the C++ decision-makers are very averse to new keywords.

Yes, the standards body have been very keen at avoiding new keywords, but things are shifting - mostly due to modern internet technology. Whenever new keywords are suggested, Google Code and similar databases are searched for existence of such a keyword in existing code. Also, context-sensitive keywords are a hot topic as well (MS did a lot with those in C++/CLI where for example "ref" is only a keyword when it's followed by "class"), and they could easily fit both usecases in your post.