C 我们应该禁用编译器优化，直到程序没有bug吗？

有时编译器优化会隐藏错误；例如：

double val = sin(1.5);

如果在未链接数学库的情况下启用了编译器优化，这将进行编译，因为编译器将计算并替换

sin（1.5）

的值

---

在程序没有bug之前禁用编译器优化是一种好做法吗？

我总是使用以下参数：所有部署的代码都经过优化。因此，不必要地使用未优化的代码来阻碍开发过程是毫无意义的。特别是，使用未优化的代码进行任何性能评估是没有意义的。关闭优化器的唯一原因是能够在调试器中跟踪程序，而不是其他。如果关闭优化会破坏构建，那将是一个麻烦，仅此而已

更糟糕的是相反的效果，程序由于优化而突然失败。这是你需要防范的影响，因为这是你的用户会生气的影响。由于巧妙的优化器和语言定义中未定义的行为的结合，这种效果很容易发生

因此，我尝试至少使用

-O2

进行所有测试，并且仅当我需要使用调试器时才切换到

-O0

。

因为没有人将其作为答案，所以我尝试了一下

在程序没有bug之前禁用编译器优化是一种好的做法吗

我不推荐。相反，我也会定期在发布模式下测试代码（启用优化）。我个人也遇到过一些bug，我见过很多这样的情况，代码在调试模式下运行得很好，但在发布模式下崩溃或产生了奇怪的东西。（后面的一些bug与堆栈损坏有关。）

你越早意识到你有这样的错误，就越好。当您对代码的记忆仍然清晰时，您可能会更容易找到它

我看到的另一件事是由于只在调试模式下运行的代码片段中的副作用而导致的bug。这些显然是开发人员的错误，但是您越早注意到它，就越有可能修复它

除非我需要调试器，否则在发布模式下开发对我来说似乎有点过头了。在调试模式下，您可能会在第三方库中得到许多有用的检查，从而减少调试所花费的时间

---

简而言之：在调试模式下开发，但在发布模式下定期测试。

你的意思是存在无bug代码吗？这可以说不是bug，那么…另一方面，编译器优化有时会突出错误，至少在具有未定义行为的语言中，优化可以利用这些错误（C，C++）。在调试代码（使用调试器）时，编译器通常会禁用许多优化，以便将源代码与实际运行的机器代码更匹配，以便您可以单步执行源代码或机器代码。因此，如果您使用的是集成调试之类的工具，那么您实际上可能正在运行一个未经优化的代码。@PaulGriffiths:OP是非常正确的。当编译器优化掉函数调用时（通过预计算结果），它可以防止链接器错误。