c++ - 值语义与具有大型数据结构的输出参数

Question

2013 Keynote: Chandler Carruth: Optimizing the Emergent Structures of C++

• 42:45
  您不需要输出参数，我们在 C++ 中有值语义。 ... 任何时候你看到有人争论说 nonono 我不会按值(value)返回，因为复制成本太高，从事优化器的人说他们错了。好的？我还从未见过该论点是正确的一段代码。 ...人们没有意识到值语义对优化器有多么重要，因为它完全阐明了别名场景。

谁能把这个放在这个答案的上下文中:https://stackoverflow.com/a/14229152

我听说不断重复，但是，对我来说，返回某些内容的函数是来源。输出参数通过引用从函数中提取该特性，从函数中删除这种硬编码特性允许人们在外部管理，而不是如何存储/重用输出。

我的问题是，即使在那个 SO 答案的上下文中，是否有一种方法可以告诉我们，以其他等效方式重构代码，“好吧，现在看，这种方式的值语义不会” t lose for the output param version”，或者钱德勒的评论是针对某些人为的情况？ I had even seen Andrei Alexandrescu arguing this in a talk并告诉您无法逃避 using by ref output 以获得更好的性能。

要了解 Andrei 的评论，请参阅 Eric Niebler: Out Parameters, Move Semantics, and Stateful Algorithms .

Answer 1

这要么是夸大、概括、开玩笑，要么是钱德勒关于“完全合理的性能”(使用现代 C++ 工具链/库)的想法对我的程序来说是 Not Acceptable 。

我发现它的优化范围相当狭窄。由于在程序中发现的实际复杂性和设计，存在超出该范围的惩罚无法忽略 - 堆分配是 getline 示例的示例。尽管您尝试减少它们，但特定的优化可能会或可能不会总是适用于有问题的程序。真实世界的结构将引用可能混叠的内存。您可以减少它，但相信您可以消除混叠是不切实际的(从优化器的角度来看)。

当然，RBV 可能是一件好事 - 它并不适用于所有情况。甚至您引用的链接也指出了如何避免大量分配/释放。真正的程序和其中的数据结构要复杂得多。

在演讲的后面，他继续批评成员函数的使用(引用:S::compute())。当然，有一点需要注意，但是完全避免使用这些语言特性真的合理吗，因为它使优化器的工作更容易？不会。它总是会产生更具可读性的程序吗？不会。这些代码转换是否总能产生明显更快的程序？不。转换代码库所需的更改是否值得您投入时间？有时。您能否拿走一些要点并做出更明智的决定，这些决定会影响您现有或 future 的代码库？是的。

有时它有助于分解你的程序将如何执行，或者它在 C 中的样子。

优化器不会解决所有的性能问题，你不应该假设你正在处理的程序是“完全脑死亡和损坏的设计”来重写程序，你也不应该相信使用 RBV 总是会导致“完全合理的表现”。您可以利用新的语言功能并使优化器的工作更轻松，尽管有很多收获，但通常有更重要的优化需要您投入时间。

可以考虑提议的更改；理想情况下，您会在采纳这些建议之前衡量此类更改对现实世界执行时间的影响以及对您的源代码的影响。

以您的示例为例:即使按值复制+分配大型结构也会产生巨大的成本。除了运行构造函数和析构函数的成本(以及它们所获取和拥有的资源的相关创建/清理，如您引用的链接中所指出的)，即使像避免不必要的结构拷贝这样简单的事情也可以为您节省大量 CPU如果您使用引用文献(在适当的情况下)。结构拷贝可能与 memcpy 一样简单。这些不是人为的问题；它们出现在实际程序中，并且复杂性会随着程序的复杂性而大大增加。减少某些内存的别名和其他优化是否值得付出代价，是否会产生“完全合理的性能”？不总是。