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

If you are worried about dumb compilers why do you use post increment operators where the code logic doesn't care if it's a pre or post operator? Post "requires" an intermediate variable to save the pre-incremented value so it can be returned post increment.

This preference for post increment is pervasive and I can't think why that should be. To me pre-increment is king because it puts the operator out front where I can see it instead of hiding the operator behind a variable. I expect most modern compilers would optimise the code if the "return" value's not used in any case, but in an embedded context where the odd nano-second may be important using post-increment by default seems really odd if you don't trust the compiler.

Perl is the programming world's equivalent of English

Replies are listed 'Best First'.
Re^4: quickness is not so obvious
by RonW (Parson) on Jan 23, 2015 at 18:04 UTC

    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.

[reply]

      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
[reply]

        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,

[reply]

        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.

[reply]
[d/l]
[select]

In Section Meditations