I have a question that has bugged me about D and C's "undefined" operator order restriction.  By this, I mean that statement that it is illegal to depend on the order of side effects in statements such as "i = (j++) / (j++);".

Why is this illegal and left to the compiler?  If it is forbidden to do this, why not just specify an order at the language level, say left-to-right?

Surely, whatever the results of choosing one order can't be worse than "undefined" behaviour?  I have heard this is left open "for performance reasons" (in C); but how can performance matter in a statement that is illegal to begin with?

Kevin

kevinbealer@yahoo.com schrieb:

> I have a question that has bugged me about D and C's "undefined" operator order
> restriction.  By this, I mean that statement that it is illegal to depend on the
> order of side effects in statements such as "i = (j++) / (j++);".
> 
> Why is this illegal and left to the compiler?  If it is forbidden to do this,
> why not just specify an order at the language level, say left-to-right?

C back-ends might make evaluation order depend on the order in which stuff appears to lay on the stack - at least a normal assembly programmer definately would - perhaps it makes something simpler or faster. It has been found out that, e.g. in D a+b+c is slower than c+b+a, for a tiny function which takes a, b, and c in that order.

> Surely, whatever the results of choosing one order can't be worse than
> "undefined" behaviour?  I have heard this is left open "for performance reasons"
> (in C); but how can performance matter in a statement that is illegal to begin
> with?

Because it is generally impossible to detect this situation of interfering side-effects, whether an expression has a side effect or not. This is due to linking model, whole-program languages may work differently: Sather language always knows the side-effects, but it also fixates the execution order to be left to right. Not that it would be regarded as being a great progress in its community. But D has to retain the "weak" mode as well.

Side effects in expessions are to be avoided anyway, because they are evil - and fixed evaluation order will actually not save you from making a bug. So it is actually smarter to forbid than to propagate such a sucky programming style.

And really, there are much much more serious "features" which should bug you about C and D, if at all. I won't list them here because this might lead to a flamewar.

-eye