> 42:45
您不需要输出参数,我们在C中有值语义. …任何时候你看到有人争辩说,我不会因价值而返回,因为复制将花费太多,那么在优化器上工作的人说错了.好吧？我从来没有看到一段代码,那个论点是正确的. …人们并没有意识到价值语义对于优化器有多重要,因为它完全澄清了混叠场景.
任何人都可以将此放在这个答案的上下文中：https://stackoverflow.com/a/14229152
我听说这是重复的,但是,对我来说,一个返回东西的功能是一个来源.通过引用的输出参数将该特性从功能中消除,并且从功能中去除这样的硬编码特性允许一个外部管理,如何存储/重复使用输出.
我的问题是,即使在这样的答案的背景下,有没有办法告诉,重新编码代码一些其他等同的方式,“好的现在看到,这种方式的价值语义不会失去输出param版本”,或钱德勒的评论是针对一些设想的情况？ I had even seen Andrei Alexandrescu arguing this in a talk,并告诉你不能逃脱使用ref输出更好的性能.
另请参阅Andrei的评论见Eric Niebler: Out Parameters,Move Semantics,and Stateful Algorithms.
解决方法
我发现这是一个相当狭窄的优化范围.惩罚存在于该范围之外,由于程序中发现的实际复杂性和设计而无法忽略,堆分配是getline示例的一个例子.尽管您尝试减少它们,但是具体的优化可能也可能并不总是适用于有问题的程序.现实世界的结构将引用别名的内存.您可以减少它,但相信您可以消除混叠(从优化器的角度来看)是不现实的.
当然,RBV可以是一件伟大的事情 – 它不适合所有的情况.即使你引用的链接也指出了如何避免大量的分配/释放.真正的程序和在其中发现的数据结构要复杂得多.
在接下来的谈话中,他继续批评使用成员函数(ref：S :: compute()).当然,有一点要拿走,但是完全避免使用这些语言功能真的是合理的,因为它使优化器的工作更容易吗？是否会总是导致更可读的程序？这些代码转换是否总是能够显着加快程序？是否需要更改变更您的代码库值得您投资的时间？有时.你能拿走一些积分,做出更明智的决定,影响你现有或将来的一些代码库？是.
有时它有助于分解你的程序将如何执行,或者在C中看起来如何.
优化器不会解决所有的性能问题,您不应该重写程序,假定您正在处理的程序是“完全死亡和断开设计”,也不应该相信使用RBV会始终导致“完全合理的性能”.您可以利用新的语言功能,并使优化器的工作更容易,尽管有很多优点往往是更重要的优化来投入时间.
考虑建议的变化是很好的理想情况下,您可以在采用这些建议之前衡量这些变更对现实执行时间的影响以及对源代码的影响.
举个例子：即使按值分配大型结构,也可能产生巨大的成本.除了运行构造函数和析构函数的成本(以及它们相关的创建/清除所获取和拥有的资源之外,如您所引用的链接中所指出的),即使避免不必要的结构副本也是简单的方式,可以节省一吨cpu如果您使用引用(如果适用)的话.结构拷贝可能与memcpy一样简单.这些都不是问题;它们出现在实际程序中,并且复杂性可以随着程序的复杂性而大大增加.减少一些内存的别名和其他价值成本的优化,是否会导致“完美合理的性能”？不总是.