与c++编码标准相关的过早优化和过早悲观

我认为，他所说的过早悲观的意思正好是过早优化的反面:从根本上忽视使用哪种数据结构和算法。

不成熟的优化通常与算法的微小细节有关，这些细节可以在以后进行调整，并且不需要在开始时注意。

过早悲观关注的是代码架构的高层设计:例如，对于库来说，一个根本低效的接口不能在以后通过优化来修复，因为公共接口几乎是一成不变的。

Herb的意思是，当你面临两个同样可读的选项时，总是选择最有效的那个。

使用std::vector::reserve()或最佳标准容器或算法不是过早优化。然而，不使用它们将是过早悲观。

不成熟的优化是指为了一些可能不值得的"优化"而牺牲可读性。使用分析器

在编程时可以进行小型和大型的选择。

悲观是指以一种"阻止编译器做好工作"的方式编写代码。一个典型的例子是，当函数非常小且简单(例如A {s,g}字母)时，不要将函数放在允许它们内联的地方。这可能会使函数花费10倍的时间，这是一件很简单的事情，"正确"。

我在这个网站上发现了几次悲观的情况，当"A>>= 1"同样合适时，使用"A/= 2;"。如果我们知道a不是负的，那么左移和除法也有同样的效果，但即使当编译器优化除法时，它几乎总是产生更多的代码来处理"它可能是负的"情况——在某些情况下，额外的代码可能会对性能造成真正的影响。

过早优化是当你展开循环或以其他方式使代码更复杂，只是因为你不相信编译器能做好工作-通常没有证据表明它不能做好工作。

另一个例子是"不使用std::vector"，而是使用自己的expandable array，因为"vector太慢了"，甚至没有使用std::vector测试代码。

我倾向于认为过早悲观只是对导致过早优化的性能需求的误解。例如，你错误地认为你的代码不会执行得足够快或使用太多的资源(悲观)，所以你在不必要的地方进行优化。

随着越来越多的庞大数据集的出现，我倾向于看到更频繁的逆转，即缺乏足够的悲观主义导致选择的算法无法扩展以满足用户需求。这通常伴随着这样一种信念，即编译器优化是糟糕算法选择的某种替代品。

在按引用传递时定义按值传递参数适当的

是避免过早悲观化的最简单示例之一。它不需要花费任何成本，而且会成为你的第二天性，而且可以避免一些性能缺陷。

假设您正在参考这本书- c++编码标准:101规则，指导方针和最佳实践。2004年10月ISBN: 0321113586 -项目9和25给出了几个例子: