Is there a performance difference between i++ and ++i in C++?

前端 未结 17 1957
臣服心动
臣服心动 2020-11-21 17:15

We have the question is there a performance difference between i++ and ++i in C?

What\'s the answer for C++?

相关标签:
17条回答
  • 2020-11-21 18:10

    @wilhelmtell

    The compiler can elide the temporary. Verbatim from the other thread:

    The C++ compiler is allowed to eliminate stack based temporaries even if doing so changes program behavior. MSDN link for VC 8:

    http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx

    0 讨论(0)
  • 2020-11-21 18:12

    I would like to point out an excellent post by Andrew Koenig on Code Talk very recently.

    http://dobbscodetalk.com/index.php?option=com_myblog&show=Efficiency-versus-intent.html&Itemid=29

    At our company also we use convention of ++iter for consistency and performance where applicable. But Andrew raises over-looked detail regarding intent vs performance. There are times when we want to use iter++ instead of ++iter.

    So, first decide your intent and if pre or post does not matter then go with pre as it will have some performance benefit by avoiding creation of extra object and throwing it.

    0 讨论(0)
  • 2020-11-21 18:13

    @Ketan

    ...raises over-looked detail regarding intent vs performance. There are times when we want to use iter++ instead of ++iter.

    Obviously post and pre-increment have different semantics and I'm sure everyone agrees that when the result is used you should use the appropriate operator. I think the question is what should one do when the result is discarded (as in for loops). The answer to this question (IMHO) is that, since the performance considerations are negligible at best, you should do what is more natural. For myself ++i is more natural but my experience tells me that I'm in a minority and using i++ will cause less metal overhead for most people reading your code.

    After all that's the reason the language is not called "++C".[*]

    [*] Insert obligatory discussion about ++C being a more logical name.

    0 讨论(0)
  • 2020-11-21 18:14

    Mark: Just wanted to point out that operator++'s are good candidates to be inlined, and if the compiler elects to do so, the redundant copy will be eliminated in most cases. (e.g. POD types, which iterators usually are.)

    That said, it's still better style to use ++iter in most cases. :-)

    0 讨论(0)
  • 2020-11-21 18:17

    It's not entirely correct to say that the compiler can't optimize away the temporary variable copy in the postfix case. A quick test with VC shows that it, at least, can do that in certain cases.

    In the following example, the code generated is identical for prefix and postfix, for instance:

    #include <stdio.h>
    
    class Foo
    {
    public:
    
        Foo() { myData=0; }
        Foo(const Foo &rhs) { myData=rhs.myData; }
    
        const Foo& operator++()
        {
            this->myData++;
            return *this;
        }
    
        const Foo operator++(int)
        {
            Foo tmp(*this);
            this->myData++;
            return tmp;
        }
    
        int GetData() { return myData; }
    
    private:
    
        int myData;
    };
    
    int main(int argc, char* argv[])
    {
        Foo testFoo;
    
        int count;
        printf("Enter loop count: ");
        scanf("%d", &count);
    
        for(int i=0; i<count; i++)
        {
            testFoo++;
        }
    
        printf("Value: %d\n", testFoo.GetData());
    }
    

    Whether you do ++testFoo or testFoo++, you'll still get the same resulting code. In fact, without reading the count in from the user, the optimizer got the whole thing down to a constant. So this:

    for(int i=0; i<10; i++)
    {
        testFoo++;
    }
    
    printf("Value: %d\n", testFoo.GetData());
    

    Resulted in the following:

    00401000  push        0Ah  
    00401002  push        offset string "Value: %d\n" (402104h) 
    00401007  call        dword ptr [__imp__printf (4020A0h)] 
    

    So while it's certainly the case that the postfix version could be slower, it may well be that the optimizer will be good enough to get rid of the temporary copy if you're not using it.

    0 讨论(0)
提交回复
热议问题