C++ 为什么要避免在C++；？

我听到一位教授说“避免后缀运算符，因为上下文允许选择前缀”。我搜索了一下，但在stackoverflow中找不到解释这一点的相关帖子

---

当我们能够选择其中一种时，为什么要选择

前缀
操作符++而不是
后缀
操作符+？
我很肯定你的教授在谈论前缀和后缀++操作符之间的旧速度差异。我还非常确定，选择哪种编译器已经不再重要，因为现代编译器通常足够聪明，能够识别它是否可以优化

此外，根据您的代码，可能需要使用其中一种来确保正确性。
前缀运算符可能比后缀运算符快，具体取决于其操作的类型。它不应该再慢了

对于大多数固有类型，速度应该相同。但是，许多自定义迭代器需要为某些状态对象创建一个额外的副本，以便正确实现后缀运算符。
前缀运算符++只执行一个操作—增加值

后缀运算符++执行三个操作：保存当前值、增加值和返回旧值

前缀版本在概念上更简单，并且总是（直到奇怪的运算符重载）至少与后缀版本一样有效。
为了实现后缀运算符，必须获取原始对象的副本，因为这是返回给您的

对于prefix操作符，您可以取回新对象，从而节省复制开销

一些人（正确地）会告诉你，编译器将优化无意的后缀拷贝；例如，在代码中，如for（int n=0；n

我总是喜欢看
++n

事实上，我宁愿把这种语言叫做++C；不是C++！ 除了风格问题，没有真正的原因。一个注意到
专家推荐了一次，大家都盲目地跟着，
虽然我所做的措施表明它没有任何作用
差别

如果你要开始一个绿色领域的项目，我会使用前缀，
但动机只是为了避免愚蠢的讨论
问题如果我在处理现有代码，我将继续使用
最常见的是什么，因为在实际代码中
绝对没有区别，尽管有相反的说法
 这主要是为了避免使用后缀操作复制对象。我们的教授正在过早地进行微观优化。他还引用了一句古老的格言，这句格言在现代编译器中已基本过时。@johndilling STL最初提出时，这句格言已经过时。即使是最古老的C++编译器也做了必要的优化。我认为这没什么关系。STL的前提是复制迭代器是一个简单的操作，当Herb第一次提到这一点时，我实际测量了一下。当时，我预计一些更复杂的迭代器（例如，映射上的反向迭代器）会有一点不同，但没有。。。性能差异是另一个性能神话。
struct Foo{Foo operator++（int）；Foo&operator++（）；Foo（Foo const&）；}
--您是否看到后缀和前缀签名的差异可能导致性能上的巨大差异？诚然，大多数迭代器不会有这样的差异，如果内联编译器可以注意到副本可以被丢弃，那么我肯定可以用postfix++编写一个比prefix慢得多的类。雅克，这不会告诉你编译器优化后的性能差异。@greedyforda:不，但它告诉您前缀不应该慢，也可能快。那么为什么不直接使用它而不是争论它呢？你说“postfix++做3个操作”，但如果编译器可以优化它们，情况就不是这样了。@JohnDibling:问题不在于性能。问题是，代码要求的是它不需要的东西，这让人困惑。这一点很好。这在我的脑海中澄清了我自己关于前缀/后缀的经验法则——没有经验法则。知道他们都做什么，并使用你需要的。这会根据上下文的不同而有所不同。int i=++x产生的值与int i=x++不同。这是一个相当重要的区别。