• kevinbealer yahoo.com (10/10) Apr 20 2004 I have a question that has bugged me about D and C's "undefined" operato...
• Ilya Minkov (21/31) Apr 20 2004 C back-ends might make evaluation order depend on the order in which

kevinbealer yahoo.com writes:

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

Ilya Minkov <minkov cs.tum.edu> writes:

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