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

Does this rule also exclude call(i++) ?

Yes. Increment, decrement and assignment operators are not allowed in expressions that are parameters to functions.

Replies are listed 'Best First'.
Re^11: quickness is not so obvious
by BrowserUk (Patriarch) on Jan 26, 2015 at 23:05 UTC
    Increment, decrement and assignment operators are not allowed in expressions that are parameters to functions.

    Sorry, but a quick review of the subthread doesn't reveal why that is so. Could you explain please?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

      It's another guideline I didn't previously mention.

      In theory, it could be considered a corollary to the "assignment and assignment-like ops must be left most op" when you think of function call as a named op. However, I'm pretty sure the people who wrote the guidelines weren't thinking that way. They just were seeking ways to avoid non-obvious side effects.

        Do you agree with these guidelines?

        I won't argue with you about them. I once (long ago) was expected to work under a set of C programming guidelines that insisted that C header files should be named 'xxxx.C.Header.File'.

        It turned out that the job of devising the company's (IBM UK) C programming guidelines had been handed -- by the manager designated to head-up the new project which was their first in C; and whom had never done any C -- to a summer intern (whom had also never done any C). They'd been handed a copy of the companies PL/1 programming guidelines and a copy of "The C programming language" and told to just do it.

        It didn't take too long to get some of the more ridiculous ones -- like the file names which the compiler simply couldn't handle -- overturned. Some of the others were directly cribbed from the PL/1 programming standards were harder -- because they were used to them and (presumably) knew their value in that language. It was only when we pointed out that many of them simply had no meaning in the C language that they went out a bought a set of C guidelines from some university.

        Not perfect as they were K&R style -- function args named in the parens, but typed between the parens and the opening brace. etc. -- but for the most part, at least familiar.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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". I'm with torvalds on this
        In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked