i++有时比++ I快!

对于使用ILP(指令级并行)的x86架构，i++在某些情况下可能优于++i。

为什么?因为数据依赖关系。现代cpu可以并行化很多东西。如果接下来的几个CPU周期对i的增量值没有任何直接依赖，CPU可能会省略微码来延迟i的增量，并将其塞到“空闲插槽”中。这意味着您实际上得到了一个“免费”增量。

我不知道ILE在这种情况下走多远，但我认为如果迭代器变得太复杂，并做指针解引用，这可能不会工作。

下面是Andrei Alexandrescu对这个概念的解释:https://www.youtube.com/watch?v=vrfYLlR8X8k&list=WL&index=5

下面是自增操作符位于不同转换单元时的基准测试。g++ 4.5编译器。

现在先忽略样式问题

// a.cc
#include <ctime>
#include <array>
class Something {
public:
    Something& operator++();
    Something operator++(int);
private:
    std::array<int,PACKET_SIZE> data;
};

int main () {
    Something s;

    for (int i=0; i<1024*1024*30; ++i) ++s; // warm up
    std::clock_t a = clock();
    for (int i=0; i<1024*1024*30; ++i) ++s;
    a = clock() - a;

    for (int i=0; i<1024*1024*30; ++i) s++; // warm up
    std::clock_t b = clock();
    for (int i=0; i<1024*1024*30; ++i) s++;
    b = clock() - b;

    std::cout << "a=" << (a/double(CLOCKS_PER_SEC))
              << ", b=" << (b/double(CLOCKS_PER_SEC)) << '\n';
    return 0;
}

O (n)增加

Test

// b.cc
#include <array>
class Something {
public:
    Something& operator++();
    Something operator++(int);
private:
    std::array<int,PACKET_SIZE> data;
};


Something& Something::operator++()
{
    for (auto it=data.begin(), end=data.end(); it!=end; ++it)
        ++*it;
    return *this;
}

Something Something::operator++(int)
{
    Something ret = *this;
    ++*this;
    return ret;
}

结果

在虚拟机上使用g++ 4.5的结果(计时以秒为单位):

Flags (--std=c++0x)       ++i   i++
-DPACKET_SIZE=50 -O1      1.70  2.39
-DPACKET_SIZE=50 -O3      0.59  1.00
-DPACKET_SIZE=500 -O1    10.51 13.28
-DPACKET_SIZE=500 -O3     4.28  6.82

O(1)增加

Test

现在让我们看看下面的文件:

// c.cc
#include <array>
class Something {
public:
    Something& operator++();
    Something operator++(int);
private:
    std::array<int,PACKET_SIZE> data;
};


Something& Something::operator++()
{
    return *this;
}

Something Something::operator++(int)
{
    Something ret = *this;
    ++*this;
    return ret;
}

它对增量没有任何影响。这模拟了增量具有恒定复杂度的情况。

结果

结果现在变化很大:

Flags (--std=c++0x)       ++i   i++
-DPACKET_SIZE=50 -O1      0.05   0.74
-DPACKET_SIZE=50 -O3      0.08   0.97
-DPACKET_SIZE=500 -O1     0.05   2.79
-DPACKET_SIZE=500 -O3     0.08   2.18
-DPACKET_SIZE=5000 -O3    0.07  21.90

结论

属性

如果不需要前一个值，请养成使用预递增的习惯。即使与内置类型保持一致，您也会习惯它，如果您用自定义类型替换内置类型，也不会有遭受不必要性能损失的风险。

Semantic-wise

i++表示递增i，但我对之前的值感兴趣。 ++i表示自增i，我对当前值感兴趣或者自增i，对之前的值不感兴趣。再说一次，你会习惯的，即使你现在还不习惯。

Knuth。

过早的优化是万恶之源。过早的悲观也是如此。

是的。有。

++操作符可以定义为函数，也可以不定义为函数。对于基本类型(int, double，…)，操作符是内置的，因此编译器可能能够优化您的代码。但对于定义了++运算符的对象，情况就不一样了。

操作符++(int)函数必须创建一个副本。这是因为postfix ++被期望返回一个与它所保存的值不同的值:它必须将其值保存在一个临时变量中，自增其值并返回临时值。在操作符++()，前缀++的情况下，不需要创建一个副本:对象可以自增，然后简单地返回自己。

下面是关于这一点的一个例子:

struct C
{
    C& operator++();      // prefix
    C  operator++(int);   // postfix

private:

    int i_;
};

C& C::operator++()
{
    ++i_;
    return *this;   // self, no copy created
}

C C::operator++(int ignored_dummy_value)
{
    C t(*this);
    ++(*this);
    return t;   // return a copy
}

每次调用操作符++(int)都必须创建一个副本，编译器对此无能为力。当有选择时，使用运算符++();这样就不需要保存副本。在很多增量(大循环?)和/或大对象的情况下，它可能很重要。

++i比i = i +1快，因为在i = i +1中发生了两个操作，第一个递增，第二次将其赋值给一个变量。但是在i++中只进行增量操作。

@Ketan

.．.加薪忽略了关于意图和性能的细节。有时我们想用iter++而不是++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.

毕竟，这就是语言不叫“c++ C”的原因。[*]

[*]插入关于c++ C是一个更合乎逻辑的名称的必要讨论。

有意的问题是关于什么时候结果是未使用的(这从C的问题中很明显)。有人能解决这个问题吗，因为这个问题是“社区维基”?

关于过早优化，Knuth经常被引用。这是正确的。但是Donald Knuth永远不会用你现在看到的那些可怕的代码来辩护。见过Java整数(不是int)中的a = b + c吗?这相当于3次装箱/开箱转换。避免这样的事情很重要。无用地写i++而不是++i也是同样的错误。 编辑:正如phresnel在评论中所言，这可以总结为“过早的优化是邪恶的，过早的悲观也是”。

甚至人们更习惯于i++这一事实也是一个不幸的C遗产，是由K&R的一个概念错误造成的(如果你遵循意图论点，这是一个合乎逻辑的结论;为K&R辩护因为他们是K&R是毫无意义的，他们很伟大，但作为语言设计师他们并不伟大;C设计中存在无数错误，从gets()到strcpy()，再到strncpy() API(它应该从第一天开始就有strlcpy() API)。

顺便说一句，我是那些不太习惯c++的人之一，觉得c++ I读起来很烦人。尽管如此，我仍然使用它，因为我承认它是正确的。