Re^2: Perl vs C

[Marshall]

I looked at this other post. re: C
k = i++ + i++;
That is "weird looking". I recommend a more clear statement of intent!
x = i++; /*maybe*/
k = x + x; /*maybe ???? */
I am not sure what the precedence rules are with 3 +++ in row. I recommend that you use a couple of statements to make this more clear.

BTW: In Perl, sub x (--$i, $i++) behavior is also undefined.
The order of operands to a sub can be evaluated in any order. This is true in C also.

[ikegami]

In Perl, sub x (--$i, $i++) behavior is also undefined

Not really. On all platforms, operands are always evaluated from left to right except for assignment operators, where it's right to left. People regularly rely on this.

sub foo { shift->bar('foo', @_)) }

{
   my $x = $x;
   ...
}

The latter is even documented.

The problem is that it gets really tricky when lvalues are involved.

f($i, --$i, $i);

The first argument is evaluated first, but it's still affected by the decrement because Perl passes by reference.

[Marshall]

I think we both might be right on this question. There is one issue of lvalue calculation in a single statement. Then there is the issue of what happens in a sub call with say foo (++I, --I). In C, we don't know whether "I" will get incremented or decremented first. This is like when you go to the doctor and you say, "it hurts when I press here", and he says, "don't do that".

The fact that we are "arguing" about some syntax says to me that the syntax isn't clear enough. I am not gonna argue precedence.. Hey, that there is even a question at this level means it the code was not clear enough to begin with!

Think about what will happen say 2 years from now? My opinion is that clear code is good code.

[ikegami]

In C, we don't know whether "I" will get incremented or decremented first.

Yes, you've already said that. And you said it was the same for Perl. I replied that in Perl, you do know.

The fact that we are "arguing" about some syntax

Since when were we talking about syntax? Our posts are entirely about operand evaluation order.

I am not gonna argue precedence.

Since when were we talking about operator precedence? Our posts are entirely about operand evaluation order.

Think about what will happen say 2 years from now?

Nothing. Operand evaluation order has been unchanged for at least a decade, probably since day one, and its the intention of developers not to change it. They couldn't even if they wanted because it would break existing in subtle ways.

My opinion is that clear code is good code.

Of course. And I gave two examples of clear code that relies on operand evaluation order.