#pragma 警告(push) 没有 #pragma 警告(pop)答案

【问题标题】：#pragma warning(push) without #pragma warning(pop)#pragma 警告(push) 没有 #pragma 警告(pop)
【发布时间】：2012-08-16 22:45:32
【问题描述】：

在 Visual Studio 2010 中使用 C++ Native 解决方案。

#pragma warning (push) 用于 cpp 文件的开头，在所有包含之后。之后，#pragma warning(disable : XXXX) 发出了一些禁用警告。

在文件末尾省略#pragma warning(pop) 可能会产生什么后果？

谢谢

【问题讨论】：

未弹出的警告状态将开始在您的计算机上堆积。最终可能需要您聘请专业的警告状态维护人员来清理它们。只是在开玩笑。没有不良影响。不过，我想知道，如果您不打算将其弹出，那么您为什么要推动警告状态。
但是请注意，这可能会使代码的未来维护者感到困惑，他们会提出与您在这里提出的完全相同的问题。
我实际上是在修复现有旧代码中的错误。我担心的是它是否会影响其他（独立）编译单元（cpp 文件）。
就像传说中的国王要奖励国际象棋的发明者。您太低估了 2 的幂。拥有一百万个#pragmas 只需要 20 次复制/粘贴。编译它看看会发生什么，现在你知道了。

【解决方案1】：

如果您有任何其他源文件#include 该 cpp 文件，那么编译外部文件时的警告状态将被搞砸——它可能无法在发出警告时发出警告。

但是请注意，#includecpp 文件被认为是错误的格式和代码异味；在某些罕见的情况下，它可能是正确的做法（例如构建系统将#includes 多个源文件合并为一个以减少编译时间，有点像预编译头文件），但几乎总是错误的要做的事情，即使它设法编译和链接没有错误。

如果该源文件在其他任何地方都不是#included，那么假设编译器一开始没有抱怨这种不匹配，那么没有#pragma warning(pop) 将不会产生任何不利后果。

【讨论】：

【解决方案2】：

由于这是仅编译器设置，因此不会对程序本身产生任何影响。它可能会搞砸外部包含的警告。

【讨论】：

如果您包含一些外部库，您还需要为其编译 cpp。在我最新的项目中，我使用 3rd 方库来压缩/解压缩数据，并且该代码使用#pragma 警告保护来避免编译期间的警告。只是如果忘记弹窗，可能是其他文件的设置有误，但应用程序激活与否不会有任何区别。
我明白你的意思。它就像推送警告，更改而不是在我的 cpp 文件中包含的库头中弹出。但就我而言，在所有包含之后，一切都在发生。