Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Incrementing a Hash Value

by Abigail-II (Bishop)
on Jun 14, 2002 at 10:57 UTC ( #174451=note: print w/ replies, xml ) Need Help??


in reply to Incrementing a Hash Value

$thes_name{$fields[1]} = thes_name{$fields[1]}++;
This is just a version of the canonical:
$i = $i ++;
DO NOT DO THAT. Now you have an expression in which you are modifying $i twice. It's behaviour is undefined. If you want to increment the value, just use:
thes_name {$fields [1]}++;
That's all.

Abigail


Comment on Re: Incrementing a Hash Value
Select or Download Code
Re: Re: Incrementing a Hash Value
by marvell (Pilgrim) on Jun 14, 2002 at 11:39 UTC
    Is it undefined, or does do this:
    # basic form $i = $i++; # long hand $k = $i; $i++; $i = $k;

    --
    ¤ Steve Marvell

        I'm definitely not qualified to argue whether this behavior should be considered 'undefined', but I haven't seen any pointers to documentation that says that it is.

        perlop is written in a language which is a little less than explicit than Perl, but it doesn't say that ++ and -- work exactly as in C.

        In fact, perlop says:
        "++" and "--" work as in C. That is, if placed before a variable, they increment or decrement the variable before returning the value, and if placed after, increment or decrement the variable after returning the value.

        In other words, the auto-increment operator works as in C in the specific way mentioned. (perlop then goes on, in the next paragraph, to explain one way in which the perl implementation differs from C.)


        Impossible Robot

      Is it undefined, or does do this: $k = $i; $i++; $i = $k;

      Both.

      $i++ stores the old value, increases the value, and then sets the return value to the stored old value. Although that is true for all versions of Perl, its behaviour is not documented. Actually, it is documented, but wrong:

      [...] increment or decrement the variable after returning the value. [...] -- perlop
      It doesn't increment after returning. It increments first, and then returns the old value.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        That sounds well defined to me. If it has a predicible behaviour, even if it's not useful, it's defined.

        I must be missing something.

        --
        Steve Marvell

        It doesn't increment after returning. It increments first, and then returns the old value.
        No, and that's the entire problem. You do not know when the increment will happen, that is specifically left undefined. (It was left undefined in C to give implementers of compilers all sorts of freedom to optimize it - idem for Perl). What a specific version of Perl does not gives you absolutely no garantee what it will do in a next version.

        Abigail

Re: Re: Incrementing a Hash Value
by Juerd (Abbot) on Jun 14, 2002 at 12:51 UTC

    $i = $i ++; Its behaviour is undefined.

    It is defined. The ++ operator has nothing to do with this, in Perl. You're right about perlop, and with multiple increments/decrement the order in which things happen is undefined (well, not always. But it is not clear either). But that isn't really what we're dealing with. This is an assignment, just like any $i = EXPR. In this case, EXPR is $i++, which causes $i to be incremented, but returns the old value. The value of EXPR is assigned to $i, so as an end result nothing happens. If $i is tied, FETCH, STORE and STORE are called.

    $i = 5; $i = $i++; print $i, "\n"; # 5\n
    1. $i is set to 5
    2. $i is incremented, new value is 6
    3. old value (5) is used as the rhs of the assignment operator
    4. $i is set to that value, old value was 6, new value is 5
    5. $i and newline are printed
    $i = 5; $i = ++$i; print $i, "\n"; # 6\n
    1. $i is set to 5
    2. $i is incremented, new value is 6
    3. new value (6) is used as the rhs of the assignment operator
    4. $i is set to that value, old value was 6, new value is 6
    5. $i and newline are printed

    I have tried this with Perl 5.005 and 5.6.1.

    Note: I agree that $i = $i++ is bad style and should never ever be used in non-obfu.

    - Yes, I reinvent wheels.
    - Spam: Visit eurotraQ.
    

      This is so utterly wrong, and it's unbelievable that after so many years, people keep iterating the wrong myths.

      Please do provide a pointer to the documentation that garantees things will happen this way. All $i ++ is saying that $i will be incremented after the value is returned. But it is nowhere specified that $i will be incremented before or after an assignment. Its behaviour is UNDEFINED.

      (And if you consider this a flame, please take your question to comp.lang.c (before you say "Perl isn't C", look up the discussion of ++ in perlop. It says that it works as in C) and really learn what being flamed is.)

      Abigail

        a pointer to the documentation that garantees things will happen this way.

        There is none.

        9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. [...]
        If you want guarantees, do not use Perl.

        But it is nowhere specified that $i will be incremented before or after an assignment.

        $i = $i++ is deparsed to ($i = ($i++)). Having $i tied and assigning to another tied variable tells me the increment happens before the assignment.

        look up the discussion of ++ in perlop. It says that it works as in C

        Perlop is wrong. Did the authors of Perl re-create all compiler/platform specific postincrement issues that exist in C? If not, how can its behaviour ever be the same?

        nowhere specified that $i will be incremented before or after an assignment

        perl's sourcecode is the specification - MANY things are not defined in the perldocs. And fortunately, this is compiler/platform independent. Anyway. Here's your specification:

        PP(pp_postinc) { dSP; dTARGET; if (SvTYPE(TOPs) > SVt_PVLV) DIE(aTHX_ PL_no_modify); sv_setsv(TARG, TOPs); if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP +OK(TOPs) && SvIVX(TOPs) != IV_MAX) { ++SvIVX(TOPs); SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK); } else sv_inc(TOPs); SvSETMAGIC(TOPs); if (!SvOK(TARG)) sv_setiv(TARG, 0); SETs(TARG); return NORMAL; }
        PP(pp_preinc) { dSP; if (SvTYPE(TOPs) > SVt_PVLV) DIE(aTHX_ PL_no_modify); if (!SvREADONLY(TOPs) && SvIOK_notUV(TOPs) && !SvNOK(TOPs) && !SvP +OK(TOPs) && SvIVX(TOPs) != IV_MAX) { ++SvIVX(TOPs); SvFLAGS(TOPs) &= ~(SVp_NOK|SVp_POK); } else /* Do all the PERL_PRESERVE_IVUV conditionals in sv_inc */ sv_inc(TOPs); SvSETMAGIC(TOPs); return NORMAL; }
        Pay special attention to dTARGET, sv_setsv and SETs in the postinc. As you can see, Perl does not delay the increment, but it does save the old value. (Which is because Perl can not optimise the same way C compilers do. At compile time, Perl cannot be sure if $i is a normal scalar or something special.)

        - Yes, I reinvent wheels.
        - Spam: Visit eurotraQ.
        

      (I really should know better than to walk into this firestorm, but I just can't help myself...)

      The two of you obviously mean different things by "defined".

      Abigail says that $i = $i++ is undefined because it is not declared in the Perl (or C) language specs. Juerd says that it is defined because it has consistently behaved in the same way for as long as anyone can remember.

      In my experience, Abigail's definition of definedness is the one most commonly (and, many would argue, most properly) used in this context. While the behaviour of $i = $i++ may be deterministic, the fact remains that its behaviour is merely an artifact of how it is implemented and should not be relied upon, because, without any implementation-independent specification of its behaviour, next release of perl is free to arbitrarily change it for any reason (or no reason at all).

      Proof by experimentation's not valid for programming languages. Bad, bad idea. (This isn't physics here--the rules of the universe are subject to change from version to versions) Only what the standard, or the documentation, guarantees is valid to count on. Everything else should be considered a quirk of the implementation.

      This bit, in particular, could easily be changed with a small cahnge to the optimizer, or optree generator. That it hasn't happened is mainly because nobody's bothered. (Well, because that part of the code's reasonably scary) Because of the way that perl works internally, both the pre and post increment versions of that code could easily resolve to 6.

      Trust Abigail here. Don't count on the behaviour of multiple manipulations to a variable without an intervening sequence point.

        Only what the standard, or the documentation, guarantees is valid to count on. Everything else should be considered a quirk of the implementation.

        Shouldn't there be a lot more documentation, then? Increments and decrements are not the only things being documented vaguely.

        - Yes, I reinvent wheels.
        - Spam: Visit eurotraQ.
        

Re: Re: Incrementing a Hash Value
by NodeReaper (Curate) on Jun 14, 2002 at 14:34 UTC

    Reason: (Petruchio) (Delete) Empty node.

    For more information on this node visit: this

Re: Re: Incrementing a Hash Value
by ignatz (Vicar) on Jun 14, 2002 at 21:20 UTC
    Why is this difficult to grasp? It seems like good common sense to me.
    ()-()
     \"/
      `                                                     
    

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://174451]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (12)
As of 2014-07-24 20:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (167 votes), past polls