in reply to Re^5: quickness is not so obvious
in thread quickness is not so obvious

Exactly. This was canvassed recently on the comp.lang.perl.misc newsgroup. The “justification” offered for preferring post-increment was this:

The point is that $l++ looks better (IMO of course) because you don't have two plus signs butted up against a dollar sign.

To which Rainer Weikusat replied:

I'm totally aware that "it looks better" because "that's how it has always been done since nineteen-seventy-something[*]" and I am actually arguing in favor of changing this habit: All other arithmetic expressions return the value computed by them, only postdecrement and -increment-expressions don't. Hence, unless this property is exploited for something, don't use them, since they're "weird and special".

[*] Some years ago, I read one of the many "your writing style has to match my intellectual laziness, otherwise, you suck" (and I'll hit you since I'm The Big Guy and you're The Insignificant Insect) which demanded that the return value of ++ must not be used because "if I need to understand the difference between ++a and a++ to understand your code, it's too complicated". And I strongly suspect this to be the 'the real postincrement motiviation' in many practical cases ...

And I suppose the commonly seen prejudice in favour of the post-increment and post-decrement forms is constantly (if subliminally) reinforced in the programmer’s mind by Bjarne Stroustrup’s choice of name for “C++”.  :-)

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^7: quickness is not so obvious
by LanX (Saint) on Jan 24, 2015 at 07:48 UTC
    I think the first time I saw an increment in a high level language was in a loop like

     for (j = 0; j < count; j++) { }

    The existence of ++j was only a side node without immediate use case.

    So maybe blame K&Rą for this implementation documentation causing a bias ultimately leading to an "it looks better" perception? (well most probably it even predates C ˛)

    Anyway optimizing for such implantation details can bite you severely when processor technology advances.

    For instance linearizing loops used to be a good idea till the memory access for the longer code was beaten by inline caches being able to hold the smaller loops in processor memory.

    So who knows what comes next?

    Personally I don't like post increment since it's a side effect sometimes causing weird undefined conditions, and in the world of concurrency side effects are the worst sin.

    But in Perl at least I have to trust that it's optimized away in void and loop context.

    Cheers Rolf

    PS: Je suis Charlie!

    updates

    ą)

    I found the oldest version in the net and it explicitly says:

    This slightly more ornate example adds up the elements of an array:

        sum = 0;
        for( i=0; i<n; i++)
               sum = sum + array[i];

    [download]

    But actually ++i would work the same, this post-increment notation hides the fact that the increment is only executed at the end of the loop's body.

    NB: like in Perl

      For Loops
       Perl's C-style "for" loop works like the corresponding "while" 
+loop;
       that means that this:

           for ($i = 1; $i < 10; $i++) {
               ...
           }

       is the same as this:

           $i = 1;
           while ($i < 10) {
               ...
           } continue {
               $i++;
           }

    [download]

    ˛) according to WP it was invented for B.

[reply]
[d/l]
[select]

In Section Meditations