程序效率 P>我想知道，与任何编程语言中的结构化编程方法相比，采用面向对象的方法来解决程序效率是否有影响，但在C++中尤其如此。。也许不是

您可以编写高效的面向对象代码。您可以编写低效的结构化代码

这取决于应用程序、代码编写的好坏以及代码优化的程度。通常，您应该编写代码，使其具有良好、干净、模块化的体系结构，并且设计良好，然后，如果您在性能方面存在问题，请优化导致性能问题的热点

---

在有意义的地方使用面向对象编程，在有意义的地方使用结构化编程。你不必在两者之间做出选择：你可以两者兼用。

如果你非常小心地避免，就不必这样做。如果您只是采用最直接的方法，使用动态分配、虚拟函数和（特别是）按值传递对象，那么肯定会有低效。

不必如此。算法就是一切。我同意封装会让你慢下来，但是编译器有优化。

< P>我记得1990年初，当C++年轻的时候，有关于这方面的研究。如果我记得正确的话，那些（写得好）C++程序的人在C中重新编码的速度大约增加了15%。C程序中的C程序，并将C++的命令式修改为面向对象的风格（但相同的算法），C++的性能相同或更好。这种明显的矛盾可以通过以下观察来解释：C程序在被翻译成面向对象的风格后，组织得更好了。在C中做的事情，因为代码太多，麻烦做得更好，在C++中更容易完成。

---

回想起来，我想知道一些结论。第二次编写一个程序总是会得到一个更好的程序，所以不一定非要使用OO风格才能产生效果。今天的计算机体系结构在硬件上支持OO程序完成的常见操作，编译器在使用指令方面也变得更好，因此，我认为，无论1992年一个虚拟函数调用的开销有多大，今天都要小得多。

如果这是计算机科学论文中的问题，你会说不

---

然而，在真实的开发环境中，如果正确使用OOP范例，这一点往往是正确的。原因是在实际的开发过程中，我们通常需要维护我们的代码库，而OOP范式可以帮助我们。OOP比C等结构化编程的一个优点是，在OOP中，代码更易于维护。当代码更易于维护时，就意味着更少的bug和修复bug的时间，以及实现新特性所需的时间。底线是，我们将有更多的时间关注应用程序的效率

可能存在这样的情况：OO方法更接近于一种解耦方法，即不同的模块不会在彼此内部来回移动。它们被限制在公共接口上，这总是有潜在的成本。例如，调用getter而不是直接检查变量；或者在默认情况下调用虚拟函数，因为对象的类型对于直接调用来说不够明显

也就是说，有几个因素削弱了这一有用的观察结果

一个编写良好的结构化程序应该具有相同的模块性（即隐藏实现），因此产生相同的间接寻址成本。调用C中的函数指针的成本可能与调用C++中的虚函数的成本非常相似。 >P >现代JIT，甚至在C++中使用内联方法，可以消除间接成本。

成本本身可能相对较小（通常每个指令调用只需要几个额外的简单操作）。在一个实际工作是在紧密循环中完成的程序中，这将是无关紧要的

最后，更模块化的风格使程序员能够处理更复杂但希望不那么复杂的算法，而不会有低级错误的危险

---

问题不在于技术，而在于心理。这就是它通过使事情变得容易来鼓励你去做的事情

打个平凡的比方，它就像一张信用卡。它比开支票或使用现金更有效率。如果是这样的话，为什么人们在使用信用卡时会遇到这么多麻烦？因为它们很容易使用，以至于被滥用。不要过度使用好东西需要很好的纪律

OO被滥用的方式是

• 创建过多的“抽象层”

• 创建过多冗余数据结构

• 鼓励使用通知样式代码，尝试在冗余数据结构中保持一致性

最好尽量减少数据结构，如果数据结构必须是冗余的，则能够容忍暂时的不一致性

增加： 作为OO鼓励的一个例子，下面是我在性能调优中有时看到的情况：有人设置

SomeProperty=true。听起来很天真，对吧？这可能会波及到包含该对象的对象，通常是通过难以跟踪的多态性。这可能意味着某个地方的某个列表或词典需要添加或删除内容。这可能意味着某些树或列表控件需要添加、删除或混合控件。这可能意味着正在创建或销毁窗口。它还可能意味着数据库中的某些内容需要更改，这些内容可能不是本地的，因此需要执行一些I/O或互斥锁

它可能是真实的