Order of evaluation - aka hidden undefined behaviours.

[Alex Rønne Petersen]

On 26-09-2012 15:34, monarch_dodra wrote:
> 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.
>

No it isn't. There's a perfectly sensible, sane, and intuitive fix for 
this: always evaluate arguments left-to-right. No exceptions.

It's not that complicated.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org