in reply to Re^3: Pre vs Post Incrementing variables
in thread Pre vs Post Incrementing variables

Who said anything about operand evaluation order? (How could there be an operand evaluation order for a unary operator.)

You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands. The order of those that aren't operands — those that are statements — is well defined.

No, the list operator is not a unary operator.

So, not an lvalue.

It appears that Perl doesn't realise that ++$i returns an lvalue (thus the syntax error), but it does. 

$ perl -E'sub { $_[0]="fred"; }->($i++); say $i'
1

$ perl -E'sub { $_[0]="fred"; }->(++$i); say $i'
fred

[download]

Ah! That well know Perl keyword 'alias'....

You understood what that code did, right? Troll. It's actually an imported function, fyi.

"It" has everything to do with the fact that the evaluation order of sub-expressions is unspecified.

No, even if "it" was specified — it's currently left to right for all the operators involved — the results would be the same.

The fact that f( ++$n, ++$n ) passes an alias to $n, rather than the value resulting from the preincrement, is just another broken behaviour.

That's entirely possible.

It is equivalent to C allowing:

Perl passes args by reference and C can't, so I don't see your point. It is equivalent to C++ allowing: 

#include <stdio.h>

void f( int &a, int &b ) {
    printf( "a: %d, b: %d \n", a, b );
    a = 3;
    b = 4;
}

int main( int argc, char ** argv ) {
    int x = 0;
    f( ++x, ++x );
    printf( "x: %d \n", x );
    return 0;
}

[download]

Which it does: 

$ g++ -o a a.cpp && a
a: 2, b: 2
x: 4

[download]

Replies are listed 'Best First'.
Re^5: Pre vs Post Incrementing variables
by BrowserUk (Patriarch) on Sep 13, 2010 at 03:45 UTC
    You did, or rather the passage you quoted. The expressions whose order of evaluation is not defined are those that are operands.

    Okay. I see where you are coming from. You think that you know better what the authors of that passage meant when they wrote it, than they did. "They" being Kernighan & Ritchie in "Appendix A:The C reference Manual" of "The C Programming Language".

    That explains a great deal.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      You think that you know better what the authors of that passage meant when they wrote it, than they did.

      Because I know something by another name, I think I know better than someone else? That makes no sense. Your post is naught but slander.

[reply]
        Because I know something by another name

        That doesn't wash either.

        1. In this: f( 1 , 2 );, The constants 1 & 2 are the operands of the comma operator.
        2. But in this: f( 1+2 , 3+4 ),

          the operands of the comma operator are the results of the subexpressions: 1+2 and 3+4.

          Ie. The operands of the comma operator are the values 3 & 7.

        By analogy, in this: f( ++$n , ++$n ), the operands of the comma operator should be the results of the preincrement subexpressions.

        Not two references to $n after both sub-expressions have been evaluated.

        As for your ploy of resorting to meta-argument to distract from the argument, I'm going to ignore it this time, just like I did last time. And the time before...

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom