C++ 为什么#pragma optimize("", off)
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/29033438/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why #pragma optimize("", off)
提问by Stokke
I'm reviewing a C++ MFC project. At the beginning of some of the files there is this line:
我正在一个 C++ MFC 项目。在一些文件的开头有这样一行：
#pragma optimize("", off)
I get that this turns optimization off for all following functions. But what would the motivation typically be for doing so?
我知道这会关闭所有以下功能的优化。但是这样做的动机通常是什么？
回答by Ray
I have used this exclusively to get better debug information in a particular set of code with the rest of the application is compiled with the optimization on. This is very useful when running with a full debug build is impossible due to the performance requirement of your application.
我专门使用它来在一组特定的代码中获得更好的调试信息，而应用程序的其余部分是在优化时编译的。当由于应用程序的性能要求而无法运行完整的调试版本时，这非常有用。
回答by Angew is no longer proud of SO
I've seen production code which is correct but so complicated that it confuses the optimiser into producing incorrect output. This could be the reason to turn optimisations off.
我已经看到生产代码是正确的，但如此复杂，以至于将优化器混淆为产生不正确的输出。这可能是关闭优化的原因。
However, I'd consider it much more likely that the code is simply buggy, having Undefined Behaviour. The optimiser exposes that and leads to incorrect runtime behaviour or crashes. Without optimisations, the code happens to "work." And rather than find and remove the underlying problem, someone "fixed" it by disabling optimisations and leaving it at that.
但是，我认为代码很可能只是有缺陷，具有未定义的行为。优化器暴露了这一点并导致错误的运行时行为或崩溃。如果没有优化，代码恰好可以“工作”。而不是找到并消除潜在的问题，有人通过禁用优化并将其留在那里来“修复”它。
Of course, this is about as fragile and workarounds can get. New hardware, new OS patch, new compiler patch, any of these can break such a "fix."
当然，这几乎是脆弱的，并且可以得到解决方法。新硬件、新操作系统补丁、新编译器补丁，任何这些都可以破坏这样的“修复”。
Even if the pragma is there for the first reason, it should be heavily documented.
即使 pragma 是第一个原因，它也应该被大量记录。
回答by JoshG
Another alternative reason for these to be in a code base... Its an accident.
这些在代码库中的另一个替代原因......这是一个意外。
This is a very handy tool for turning off the optimizer on a specific file whilst debugging - as Ray mentioned above.
这是一个非常方便的工具，用于在调试时关闭特定文件的优化器 - 正如 Ray 上面提到的。
If changelists are not reviewed carefully before committing, it is very easy for these lines to make their way into codebases, simply because they were 'accidentally' still there when other changes were committed.
如果在提交之前没有仔细更改列表，这些行很容易进入代码库，因为它们在提交其他更改时“意外地”仍然存在。
回答by Dwight
I know this is an old topic, but I would add that there is another reason to use this directive - though not relevant for most application developers.
我知道这是一个老话题，但我想补充一点，使用此指令还有另一个原因——尽管与大多数应用程序开发人员无关。
When writing device drivers or other low-level code, the optimizer sometimes produces output that does not interact with the hardware correctly.
在编写设备驱动程序或其他低级代码时，优化器有时会产生与硬件不正确交互的输出。
For example code that needs to read a memory-mapped register (but not use the value read) to clear an interrupt might be optimized outby the compiler, producing assembly code that does not work.
例如，需要读取内存映射寄存器（但不使用读取的值）来清除中断的代码可能会被编译器优化掉，从而产生不起作用的汇编代码。
This might also illustrate why (as Angew notes) use of this directive should be clearly documented.
这也可能说明为什么（如 Angew 所指出的）应该清楚地记录该指令的使用。
