为什么#pragma optimize("",off)

Sto*_*kke 14 c++ mfc visual-studio

我正在审查一个C++ MFC项目.在某些文件的开头有这一行:

#pragma optimize("", off)
Run Code Online (Sandbox Code Playgroud)

我知道这会为所有后续功能关闭优化.但这样做的动机通常是什么?

小智 26

我已经专门用它来获得一组特定代码中更好的调试信息,其余的应用程序都是通过优化编译的.由于应用程序的性能要求,在运行完整的调试版本时,这非常有用.


Rei*_*ica 17

我已经看到生产代码是正确的,但是很复杂,以至于它使优化器混淆产生不正确的输出.这可能是关闭优化的原因.

但是,我认为代码很可能只是错误,具有未定义的行为.优化器暴露了这种情况并导致不正确的运行时行为或崩溃.没有优化,代码恰好"工作".而不是找到并删除潜在的问题,有人通过禁用优化并将其保留在那里来"修复"它.

当然,这就像脆弱和变通办法一样.新的硬件,新的操作系统补丁,新的编译器补丁,任何这些都可以打破这样的"修复".

即使这个实用主义是出于第一个原因,它应该被大量记录.


Jos*_*shG 8

这些在代码库中的另一个原因......它是一个意外.

这是一个非常方便的工具,用于在调试时关闭特定文件上的优化器 - 正如上面提到的Ray.

如果在提交之前没有仔细审查更改列表,那么这些行很容易进入代码库,只是因为在提交其他更改时它们"意外"仍然存在.


小智 5

我知道这是一个古老的话题,但我想补充一点,使用该指令还有另一个原因 - 虽然与大多数应用程序开发人员无关.

在编写设备驱动程序或其他低级代码时,优化程序有时会生成不能正确与硬件交互的输出.

例如,需要读取内存映射寄存器(但不使用读取的值)来清除中断的代码可能会被编译器优化,从而产生无效的汇编代码.

这也可以说明为什么(如Angew所说)应明确记录使用该指令的原因.

  • 类似的情况是当您想要出于加密目的执行一组精确的操作时。侧通道攻击可以测量各个分支执行所需的时间/功耗,两个相似的代码路径上的优化可能不相同,从而泄露信息 https://en.wikipedia.org/wiki/Timing_attack (3认同)