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

Coding guidelines. (Which have turned in to habit.)

Though it has been several years since I last saw a compiler allocate a temporary - or even an extra register - to a post-increment or -decrement in a void context.

And even in a non-void context, on many micros, the compiler will use an in-place inc/dec instruction so no extra register or temporary required.

Replies are listed 'Best First'.
Re^5: quickness is not so obvious
by GrandFather (Saint) on Jan 24, 2015 at 05:44 UTC

    But why is it though a good thing to hide the operator after the variable? Saying "Coding guidelines" doesn't say anything about why it's a good idea. It's the reason behind the rule that I'm interested in.

    Perl is the programming world's equivalent of English

      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,

        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];

        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++; }

        ²) according to WP it was invented for B.

      The coding guidelines my colleageues and I are required to follow include:

      • When using ++ or -- in an expression, it must be the only operator in the expression. Rational: To avoid non-obvious side effects.
      • Use the postfix form when using ++ or -- in an expression. Rational: To be consistant with i += 1
      • An exception is granted is granted for do { } while (--i); Rational: This has been demonstrated to generate more efficient (faster and more compact) executable code.

      There are also guidelines that specify that an assignment or assignment-like operator must be the left most operator in expressions and only one is allowed. These are also to avoid non-obvious side effects.

      There are many other guidelines. When we violate a guideline we are required to document and justify the violation (unless there is an exception granted in the guidelines).

      As a practical matter, my colleagues and I don't make as many violations of the guidelines as we should because of the time and effort to justify the violations. Getting more exceptions added is possible but is very difficult. The do { } while (--i); exception was among the easiest as we were able to show assembly language listings, generated by the compilers, which clearly showed the difference. Even then, it involved 5 or 6 presentations and reviews to get all the needed approvals.

        > Use the postfix form when using ++ or --in an expression. To be consistant with i += 1

        but isn't this - as a sub expression - effectively a preincrement?

        Cheers Rolf

        PS: Je suis Charlie!