Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Post-decrement operator precedence. Books wrong?

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
/*
Every C++ book I've read, which has an operator precedence
table, gives the post increment operator (variablename++)
higher precedence than the assignment operator (=). Some
also explain that the value isn't incremented until after the
expression is evaluated, which makes sense since it's the
"post"decrement operator, but this is hypocritical--either
it gets incremented before, as the table would indicate,
or after, as explained, but not both. Can someone resolve
this in a way that is not hypocritical?

Here's my little test program. Compiled with DJGPP, it
seems to show that the post decrement operator has
lower precedence than the assignment operator, not
higher. Are the precedence tables in the books wrong?

Yuhef
*/

#include <iostream.h>

int main(int argc, int **argv)
{
int sale = 10;
int fame = 20;

sale = (fame++);

cout << endl << &quot;sale == &quot; << sale << &quot;, &quot; << &quot;fame == &quot; << fame << endl;
// output: sale == 20, fame == 21

return 0;
}
 
post increment/decrement will take place AFTER the assignment but pre increment/decrement will take place before


int x = 17;

int y = x++; y is = to 17
int z = ++x; z is = to 19


Matt
 
Ummm...your test program almost proves the books. Remove the parentheses from the expression and run it. If ++ had lower precedence, then the expression would be the equivalent of: (sale = fame)++;
Now, I'm not 100% on this, but my guess is that this wouldn't increment fame at all - it would increment the RESULT of (sale = fame), which should have NO effect on the variables.
Anyhoo, operator precedence != operator action. The definition of the postincrement operator is that it returns the original value, THEN increments it. I often find it handy to think of operators as function calls - they operate in a very similar fashion in C++ (the same thinking makes overloaded operators make a lot more since to me too).
 
Zyrenthian, thanks for answering but you miss my point. I know what the pre/post operators do. I question the precedence tables. The tables say postincrement has higher precedence than assignment. If this were true, then postincrement would happen before the assignment, not after. It seems to me after testing the behavior, that the tables should list postdecrement below all operators except the comma operator.

StukA, hi, the parentheses don't change the behaviour. I just included them to make it even more dramatic how late the postdecrement occurs since parentheses can usually be used to force precedence but they have no effect on the postdecrement operation, making me think that postdecrement has lower precedence than parentheses as well.

> If ++ had lower precedence, then the expression would
> be the equivalent of: (sale = fame)++;
> Now, I'm not 100% on this, but my guess is that this wouldn't
> increment fame at all - it would increment the RESULT of (sale =
> fame), which should have NO effect on the variables.

Interesting point. I have to think about that. I remember reading that the ++ and -- operators can't be applied to non-variables, so something like 7++ would be an error, as would be (sale=fame)++ i think. I can't test if it produces an error until after I post this.

> Anyhoo, operator precedence != operator action.

OK...

> The definition of the postincrement operator is that it returns
> the original value, THEN increments it.

Can you think of a code example that prooves the precedence
(not the action)?

> I often find it handy to think of operators as function
> calls - they operate in a very similar fashion in C++
> (the same thinking makes overloaded operators make
> a lot more since to me

Overloaded operators are function calls. The definition is something like
Classname::eek:perator=(/*stuff*/){/*stuff*/} I think.
For normal operators, I usually try to think of expressions and evaluations
and results of evaluations. Something subtle is getting past me though.

Yuhef
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top