Sign in to follow this  

Overloading ++ operator (prefix and postfix)

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

i recently just wrote some code to implement my own pre and post fix operators and had a few comments about the C++ designers. the first question for those that arent used to overloading is how in the world the compiler will distinguish between pre and postfix since obviously both definitions will looks like: class_something operator ++ () this would be for: ++a; //an example. well you wont be long searching to find out for postfix (a++) for example the definition of the overloader will be: class_something operator ++ (int) funny thing is is that int really isnt an argument and it certainly doesnt mean integer. its simple a signal to the compiler that this will be the postfix version of the operator. back to the C++ designers..i understand they love recycling keywords and operators to have more than 1 role in the language but why in the world they chose (int) to represent postfix is beyond me. anyone care to comment? what would you make it? how about make another keyword like (post) or something.

Share this post


Link to post
Share on other sites
I personally might have done something like the following:

//Defaults to prefix
<type> operator ++ ();

//Explicitly prefix
<type> operator ++pre ();

//Explicitly postfix
<type> operator post++ ();

Who says the declaration of a function should have to look exactly like the use of the function?

Share this post


Link to post
Share on other sites
What gives you that idea? There's nothing special about the int used in the postfix operator overload. It's not a special keyword or anything; its a regular int, provided solely to diambiguate the pre and postfix overloads by providing a different signature. In fact, you can even name the parameter and access it (although you will find it to be 0 in most cases):


class foo
{
public:
foo operator++(int bar)
{
std::cout << bar;
return (*this);
}
};

Share this post


Link to post
Share on other sites
Quote:
Original post by Agony
I personally might have done something like the following:

//Defaults to prefix
<type> operator ++ ();

//Explicitly prefix
<type> operator ++pre ();

//Explicitly postfix
<type> operator post++ ();

Who says the declaration of a function should have to look exactly like the use of the function?


yes, i understand where you are going with that but how much harder now or how much more logic will the compiler have to have..not just in this case but if you use this example and spread it across the whole language. this would include i suppose doing a string compare or string lookup for whatever operator you are wanting to overload. maybe i am looking into it too much being that i had to write a compiler in college.

Share this post


Link to post
Share on other sites
It isn't a case of how difficult it would be to implement a "special keyword" like Agony is suggesting. It's a case of there already exists a perfectly sound mechanism for accomplishing the same thing (overloading functions) so theres no reason to add an ad hoc feature to the language that would increase the complexity of the parse and provide such a fractional benefit.

It is just as trivial for the compiler to generate code to invoke operator++ with an implicit 0 passed as it is for the compiler to generate code to pass the invoking object as the implicit this pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
It's not a special keyword or anything; its a regular int, provided solely to diambiguate the pre and postfix overloads by providing a different signature. In fact, you can even name the parameter and access it (although you will find it to be 0 in most cases):


well the int doesnt mean integer and is only there to let the compiler know that this will be postfix instead of prefix. My point was is that, at least to me, they could have come up with a better way of doing that as it could be confusing..for some.

Share this post


Link to post
Share on other sites
typedef int postfix;

struct foo
{
foo operator ++(postfix);
};

Ta-DA!

But yes, they could have provided such a typedef in the standard library.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sharlin
typedef int postfix;

struct foo
{
foo operator ++(postfix);
};

Ta-DA!

But yes, they could have provided such a typedef in the standard library.


(1) Operator overloading was added to the language many many years before the C++ standard library.

(2) Introducing new keywords or reserved words will break oodles and oodles of code. C++ was not invented as a replacement for a competitor's proprietary language but as a way to make C programming safer and more expressive (and therefor more productive). That's why (a) existing keywords have multiple contextual meanings and (b) everything in the C++ standard library is in a separate namespace. That way, decades old code will continue to be compileable.

Reading "The Design and Evolution of C++" by Stroustup will give you insight into this and much much more. It's required reading for the serious programmer.

Share this post


Link to post
Share on other sites
Yes, obviously it would be in the std namespace if it were in the standard library. I'm acutely informed of the points you raised.

BTW, couldn't resist :)

typedef int postfix
typedef void prefix

struct foo
{
foo operator ++(postfix);
foo &operator ++(prefix);
};

I personally find this quite nice looking, and might consider adding those into my utilities library (inside a namespace, of course).

Share this post


Link to post
Share on other sites

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this