Order of evaluation - aka hidden undefined behaviours.

[monarch_dodra]

On Wednesday, 26 September 2012 at 12:48:19 UTC, Timon Gehr wrote:
> On 09/26/2012 02:07 PM, monarch_dodra wrote:
>> On Tuesday, 25 September 2012 at 22:58:11 UTC, Iain Buclaw 
>> wrote:
>>> Pop quiz!
>>>
>>> Without cheating, I invite people to have a good guess what 
>>> 'abc' is
>>> equal to, but just to narrow it down.
>>>
>>> 1)  It isn't "ABC".
>>> 2)  On x86/x86_64, it isn't "ACB".
>>> 3)  On everything else, it's the reverse of what you'd expect 
>>> on
>>> x86/x86_64.
>>
>> I'd say abc's value is "unspecified", and any attempt at 
>> predicting it
>> would be bogus. That's my answer anyways
>>...
>
> Why? This is not useful behaviour.

What do you mean "why"? Because order of evaluation is not 
specified, so the value of abc is not specified. That was my 
answer. The question wasn't really "what would useful behavior 
be".

IMO: useful behavior would be if it was explicitly illegal to 
modify (or modify + read) the same value twice in the same 
expression. I'd rather expressions such as:
A()[] = B()[] + C()[];
x[i] = ++i + 1;

Be illegal rather than have (an arbitrarily defined) specified 
behavior. Trying to specify a specific behavior in such cases is 
opening a can of worms.