是不是返回值优化（RVO）的一个bug？ [英] Isn't return value optimization (RVO) a bug?

问题描述

我可能会问一个蠢的问题，但我在RVO 这里查看维基百科页面，不能停止想知道这种行为是否是错误的。我试过它在我的机器和RVO完全踢在尽管优化级别。如果在构造函数中发生了 BIG 我知道它不应该，但如果呢？我不明白为什么RVO会在构造函数中存在副作用时发生。

I maybe asking a dumb question, but I looked at the wikipedia page for RVO here and could not stop wondering if that behavior is wrong. I tried it in my machine and RVO is fully kicked in despite optimization level. What if there was actually something BIG happenning in a constructor? I know it shouldn't, but what if? I can't understand why RVO would still happen when there are side effects in the constructor.

编辑： -fno-elide-constructors 似乎停止RVO。但问题仍然存在。

-fno-elide-constructors seems to stop RVO. But the question remains.

编辑2：更严重的是，有多少人知道这样的东西？它可能在标准，但它仍然是一个非常丑的功能，因为我看到它。至少编译器应该默认禁用它，并为知道这个的人提供一个开关。 ：）

On a more serious note, how many people know about something like this? It maybe in the standard, but it is still a really ugly feature as I see it. At least compilers should disable it by default and provide a switch for people who know about this. :)

编辑3：我仍然坚持这是真的很糟糕。 :)。我不认为我知道任何其他语言约束像这样直接反对语言的语法。一切都抛出编译器或链接器错误吗？

EDIT 3: I still insist that this is really bad. :). I don't think I know of any other language constraint like this that goes directly against the syntax of language. Everything else throws either compiler or linker errors right?

推荐答案

标准要求操作关注程序的可观察状态 在某些情况下不得优化， 除外。你不能依赖拷贝构造函数来执行，即使它们有你期望看到的副作用（例如，控制台输出）。

The standard mandates that operations with concern a program's observable state must not be optimized away, except for copy construction in certain circumstances. You must not rely on copy constructors to be executed, even if they have side effects you expect to see (e.g., console output).

这篇关于是不是返回值优化（RVO）的一个bug？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！