Advanced Minds

++x = 55; is not legal C because, in C, you can't apply assignment to an rvalue, and the _expression_ ++x gives an rvalue, not an lvalue. In C++, it's legal (but may result in undefined behaviour) because you can overload ++ to do what you want, so it's unnecessarily restrictive to ban the idiom in C++. According to Dr. Bjarne Stroustrup it would not cause any undefined behaviour. Mr Stroustrup's opinion is certainly valuable - but what does the C++ Standard say on the matter?

Richard Heathfield < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it wrote in message <news: This e-mail address is being protected from spam bots, you need JavaScript enabled to view it <snip ++x = 55; is not legal C because, in C, you can't apply assignment to an rvalue, and the _expression_ ++x gives an rvalue, not an lvalue. In C++, it's legal (but may result in undefined behaviour) because you can overload ++ to do what you want, so it's unnecessarily restrictive to ban the idiom in C++. According to Dr. Bjarne Stroustrup it would not cause any undefined behaviour. Mr Stroustrup's opinion is certainly valuable - but what does the C++ Standard say on the matter? I don't see anything about undefined behaviour in the standard, in fact from the standard, it appears quite unambiguous. operator= binds more tightly than operator++, so the code ++x = 55; should be equivalent to this: ++x; x=55; But if x is a user defined type, then it's anyones guess what the above code actually does.

Donovan I don't see anything about undefined behaviour in the standard, in fact Donovan from the standard, it appears quite unambiguous. operator= binds more Donovan tightly than operator++, so the code Donovan ++x = 55; Donovan should be equivalent to this: Donovan ++x; Donovan x=55; The trouble is that  ++x = 55  modifies x twice between sequence points.

to ban the idiom in C++. According to Dr. Bjarne Stroustrup it would not cause any undefined behaviour. Mr Stroustrup's opinion is certainly valuable - but what does the C++ Standard say on the matter? I don't see anything about undefined behaviour in the standard, in fact from the standard, it appears quite unambiguous. operator= binds more tightly than operator++, so the code ++x = 55; should be equivalent to this: ++x; x=55; But if x is a user defined type, then it's anyones guess what the above code actually does. In the C++ language, you still have two modifications of a single _object_ without a sequence point.  Therefore, we have a very clear case of undefined behavior. From ŠISO/IEC ISO/IEC 9899:1999 (E): 6.5 _expression_s 1 An_expression_ is a sequence of operators and operands that specifies computation of a value, or that designates an _object_ or a function, or that generates side effects, or that performs a combination thereof. 2 Between the previous and next sequence point an _object_ shall have its stored value modified at most once by the evaluation of an _expression_. Furthermore, the prior value shall be read only to determine the value to be stored.70) Foonote 70) This paragraph renders undefined statement _expression_s such as i = ++i + 1; a[i++] = i; while allowing i =i +1; a[i] = i; Hence, it is clear that:  ++x = 55; produces undefined behavior in the C++ language.

But if x is a user defined type, then it's anyones guess what the above code actually does. If you overload prefix ++ then it does what you want; in the case of a UDT, there is sequence point after the ++ function call, and the transformation to ++x; x=55; is valid.