difference between ++i & i++

This is a discussion on difference between ++i & i++ within the C++ Programming forums, part of the General Programming Boards category; Is it true that for built in types, pre increment and post increment have no effect on optimization? i.e i++ ...

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    41

    difference between ++i & i++

    Is it true that for built in types, pre increment and post increment have no effect on optimization?

    i.e i++ and ++i does not optimize the code if "i" were an "int"?

    I want to know :

    1. what is difference from optimization point of view when u write "for" loop with i++ & ++i? (assume "i" is an int)

    2. if in a statement I write ++i; instead of i++; does it optimize the code?

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,558
    I think you'd be hard pushed to find a compiler that had a difference.
    Even when you do, I'd say you'd be hard pushed to measure the difference.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    ++i is not necessarily faster than i++ for built-in types. As standalone expressions, they do the same thing and any compiler that's worth a damn will produce the same machine code for both.
    My best code is written with the delete key.

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    VC++6 used to produce different machine code for tiny examples in debug mode. Used the EAX register for the preincrement and the EDX for the postincrement.

    ++i is a good habit to get into, because it's often faster for custom types such as complicated iterators.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Registered User
    Join Date
    Apr 2006
    Posts
    2,037
    I've heard of prescript causing as much as an an 8% increase in speed on DevC++. That was on a program that had lots of loops.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,474
    Could it be with the postfix version instead?

    All the prefix operator does is to increment the value and return the incremented object. Whereas the postfix version needs to store the incremented value and return the unchanged one.

    Arguably the compiler optimizes away any differences, but for complex iterations, I would be lead to believe it's the postfix version the slowest.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F.
    Could it be with the postfix version instead?
    No, it was an increase in speed, not run time.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,474
    Yes. I misread it.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #9
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    well... post-increment can be seen as a function that stores the current value in a temporary, increments the value and returns the temporary.
    so of course some compilers might not optimize that away - even on built in types.
    signature under construction

  10. #10
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,305
    The peephole optimiser (at least) should take care of the difference for built-in types. Of course many compilers might also perform a replace-postfix-with-prefix-where-possible optimisation at an earlier phase of compilation.

    If you're a regular user of the standard C++ library, then using prefix for everything becomes the norm anyway, and there's no reason not to be consistent and use that for built-in types as well.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Finding the difference in two times
    By muthus in forum C++ Programming
    Replies: 4
    Last Post: 01-24-2008, 05:36 PM
  2. Difference Equations / Recurrence Relations
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 10-05-2007, 10:26 AM
  3. What's the difference between var++ and ++var
    By ulillillia in forum C Programming
    Replies: 6
    Last Post: 05-31-2007, 02:27 AM
  4. Replies: 6
    Last Post: 08-26-2006, 11:09 PM
  5. Difference between macro and pass by reference?
    By converge in forum C++ Programming
    Replies: 2
    Last Post: 02-26-2002, 04:20 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21