• ### Popular Now

• 12
• 12
• 9
• 10
• 13

#### Archived

This topic is now archived and is closed to further replies.

# Fun with Operator Shortcuts

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

## Recommended Posts

For you beginner''s, try to find out what o ends up being:
int o = 2;
o = --o - o--;


Rob Loach Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore "The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - The Boondock Saints

o = -1 ?

##### Share on other sites
It''s undefined by the C++ standard.

##### Share on other sites
quote:
Original post by SpaceRogue
o = -1 ?

Yup.

##### Share on other sites
o is decremented by 1 (--o) : 1
o is subtracted from itself (the postfix ++ is low priority, thus not executed until the last step) : 0
finally, o is once again decremented (this is independent of the assignment) : -1

What''s so undefined about that? Most compilers will do it like this- the fact that they don''t have to isn''t very practical. Unless you are participating in the GNU project, you are probably using one or two compilers on one or two platforms, and you don''t need to worry about stuff like the standard all the time. that said, he''s right

Brian J

##### Share on other sites
It's undefined because C++ doesn't define the order of evaluation for the operands of the binary - operator. That means that either --o or o-- could be evaluated first, it's up to the compiler which. Evaluating them in different orders leads to different final results in this case, so the result is undefined.

The only way operator precedence affects this is that it makes --o and o-- evaluate before the middle -

Also undefined behaviour doesn't mean it won't compile or run, it just means you can't say for sure what will happen. Either outcome is possible. The result you get from running the output of one compiler is irrelevant, it doesn't mean another compiler will give you the same result.

edit: cleared up a few points

[edited by - Dobbs on June 19, 2003 1:05:19 AM]

##### Share on other sites
That''s wrong. + and - evaluate left to right; that''s pretty clear in the standard (although some compilers get this wrong).

What''s not defined is whether post-decrement and pre-decrement are visible before or after other accesses to the same variable in the same expression.

The order of evaluation of arguments passed to functions is also not defined, perhaps that''s what you were thinking about when you mistakenly said that the order of - is not defined?

##### Share on other sites
This IS significant, and you should worry about it. Riddle your projects with code like that, depend on the peculariaties of one compiler for it to turn out right, and then switch to another compiler that has different behaviour. You just broke everything. Hell, even a patch or a new version of your compiler could break it. There are many similar situations where people write code that depends on the order of evaluation of subexpressions, but that order is in general undefined.

##### Share on other sites
Trust me, you guys are wrong. Google with keywords "C++ subexpression evaluation order" and read some of the listed pages. If you''re interested in really getting to the heart of it find an online copy of the C++ standard and dig through it.

The only binary operators in C++ that define the order of subexpression evaluation are && and || and ,

##### Share on other sites
To the last AP: not quite. What you''re thinking of is that those operators are left associative, which means

a + b + c

is equivalent to

(a + b) + c

and not

a + (b + c)

But that has no effect on whether a or b is evaluated first.