1. 从一次引擎升级后的满屏警告说起如果你最近把项目从UE5.1升到UE5.2或者在新机器上重新拉了一份UE5.2的源码编译大概率会在输出日志里看到一大片黄色的C4756警告内容大致是overflow in constant arithmetic而且几乎全部指向同一个地方——INFINITY宏。更让人抓狂的是这些警告往往出现在第三方库、Windows SDK头文件、甚至引擎自己的数学模块里数量动辄几百上千条把真正有价值的警告淹没得干干净净。很多人第一反应是去搜怎么关掉C4756然后加一句#pragma warning(disable:4756)了事。但如果你真的这么干了可能会发现事情没那么简单有些地方关不掉有些地方关了之后又冒出新的问题甚至在某些配置下直接变成编译错误。这背后其实牵扯到一条相当长的技术链路——从C语言标准里INFINITY宏的定义方式到MSVC编译器对常量算术溢出的处理策略再到Windows SDK版本迭代带来的头文件变化最后落到UE5.2的构建系统如何应对这一切。这篇内容就是把这整条链路拆开讲清楚。不管你是刚接触UE的新人还是已经跟MSVC打了好几年交道的老手只要你的项目涉及UE5.2在Windows平台上的编译这些信息都能帮你少走弯路。我会先讲清楚C4756到底是什么、为什么偏偏在UE5.2这个节点集中爆发然后深入INFINITY宏在MSVC下的实现细节接着给出几种不同场景下的处理方案和它们各自的代价最后分享一些我在实际项目里踩过的坑和验证过的做法。2. C4756警告的真实面目不只是溢出两个字2.1 编译器眼中的常量算术溢出C4756的全称是overflow in constant arithmetic翻译过来就是常量算术中的溢出。注意这里的关键词是常量算术不是运行时的整数溢出也不是浮点异常。它指的是编译器在编译期对常量表达式求值时发现结果超出了目标类型的表示范围。举个最直观的例子float f 1e40f; // 1e40 超出了 float 的最大表示范围约3.4e38MSVC在编译这行代码时会报C4756因为1e40这个常量在转换为float时溢出了。但有意思的是它只是一个警告不是错误——编译器会把这个值替换成INFINITY正无穷然后继续编译。这就是为什么很多项目带着几千条C4756也能正常跑起来。那为什么INFINITY宏会触发这个警告这就得看它在MSVC里是怎么定义的。2.2 INFINITY宏在MSVC下的定义方式在C99标准里INFINITY被定义为一个float类型的常量表达式表示正无穷。标准并没有规定具体怎么实现只要求它展开后是一个float类型的无穷大值。不同的编译器有不同的实现方式。在MSVC的math.h更准确地说是corecrt_math.h里INFINITY的定义大致是这样的#define INFINITY ((float)(1e300 * 1e300))看到问题了吗1e300本身是一个合法的double常量但1e300 * 1e300的结果是1e600远远超出了double的最大表示范围约1.8e308。编译器在编译期计算这个乘法时发现结果溢出于是报C4756然后把结果当作无穷大处理。最终(float)(无穷大)就是float类型的INFINITY。这个定义方式在早期的MSVC版本里一直相安无事因为那时候编译器的警告策略比较宽松或者这个表达式被放在系统头文件里警告被默认抑制了。但到了某个时间点情况变了。2.3 为什么系统头文件里的警告突然冒出来了这里有一个关键概念系统头文件system header。编译器通常会把标准库和系统SDK的头文件视为系统头文件对它们内部的代码放宽警告级别避免用户被库内部的实现细节干扰。GCC和Clang都有明确的-isystem机制来标记系统头文件路径MSVC也有类似的/external:I和/external:W0选项。问题在于MSVC对系统头文件的警告抑制并不是一直都做得很彻底。在某个版本的MSVC工具集大致是VS2022 17.4到17.6之间中编译器对常量算术溢出的检查变得更加严格而INFINITY宏所在的头文件又没有完全被当作系统头文件处理导致这个警告从系统头文件里泄漏到了用户代码的编译单元中。更麻烦的是UE5.2的构建系统在编译第三方库时会把这些库的包含路径以普通包含路径而非系统包含路径的方式传给编译器。这样一来即使INFINITY定义在Windows SDK的头文件里只要这个头文件是通过第三方库的包含链被引入的警告就不会被抑制。2.4 UE5.2为什么成了重灾区UE5.2恰好赶上了几个因素的叠加第一UE5.2默认使用的Windows SDK版本比UE5.1更新而新版本SDK的头文件里对INFINITY的使用更加广泛。第二UE5.2的构建系统在第三方库的包含路径处理上做了一些调整导致更多头文件被当作普通头文件而非系统头文件。第三UE5.2引入了一些新的数学库和平台抽象层代码这些代码大量使用了INFINITY宏。这三个因素叠加在一起就造成了UE5.2编译时C4756警告的集中爆发。我在一个中等规模的项目上实测过全新编译一次UE5.2C4756警告的数量大约在800到1500条之间具体取决于你启用了哪些模块和第三方库。3. INFINITY宏的跨编译器差异与标准演进3.1 C99、C11到C17对INFINITY的规定C99标准首次引入了INFINITY宏定义在math.h中。标准原文的描述是它展开为一个float类型的常量表达式表示正无穷大如果实现支持无穷大。注意如果实现支持这个限定——标准并没有强制要求所有实现都必须支持无穷大只是说如果支持的话INFINITY应该这么定义。C11和C17基本沿用了这个规定没有做实质性修改。但标准里有一个很重要的细节INFINITY展开后的表达式必须是常量表达式这意味着编译器必须在编译期就能确定它的值。这就解释了为什么MSVC要用1e300 * 1e300这种写法——它需要在编译期产生一个无穷大值而不能调用运行时函数。3.2 GCC和Clang是怎么做的GCC和Clang的处理方式要优雅得多。它们通常使用编译器内置函数来定义INFINITY#define INFINITY (__builtin_inff())__builtin_inff()是编译器内置的直接返回float类型的正无穷不涉及任何常量算术溢出。编译器在编译期就能识别这个内置函数并生成正确的无穷大常量完全不会触发溢出警告。这就是为什么同样的代码在GCC或Clang下编译时不会出现类似C4756的警告。MSVC没有提供等价的__builtin_inff()所以只能用常量算术的方式凑出无穷大代价就是溢出警告。3.3 MSVC的替代方案与历史包袱MSVC其实也提供了一些替代方式。比如在float.h里有_FLOAT_INFINITY相关的定义在DirectXMath里有XMInfinity常量。但这些都不是标准C的INFINITY宏不能直接替换标准库里的定义。MSVC团队在较新的版本里其实已经意识到了这个问题。在VS2022 17.7及之后的版本中INFINITY的定义方式有所调整部分场景下不再触发C4756。但问题是很多项目还在用旧版本的MSVC工具集而且UE5.2的构建系统对工具集版本有一定的要求范围不是随便升级就能解决的。3.4 一张表看清各编译器的差异编译器INFINITY定义方式是否触发溢出警告备注MSVC (旧版)(float)(1e300 * 1e300)是常量算术溢出报C4756MSVC (17.7)部分场景改用内置方式部分场景否取决于具体版本和编译选项GCC__builtin_inff()否编译器内置无溢出Clang__builtin_inff()否同GCCMinGW (GCC)__builtin_inff()否使用GCC前端行为一致这张表也顺便回答了一个常见问题为什么同样的UE项目在MinGW下编译没有这个警告因为MinGW用的是GCC前端INFINITY的实现方式完全不同。这也是msvc和mingw区别这个热搜词的一个具体体现——两者在标准库实现和编译器内置机制上的差异会在实际项目中产生完全不同的编译行为。4. 处理C4756的几种方案与各自的代价4.1 方案一全局禁用警告最省事但最危险最直接的做法是在项目的构建配置里全局禁用C4756#pragma warning(disable:4756)或者在MSVC命令行里加/wd4756。这个方案的优点是简单粗暴一行搞定。缺点是它会把所有C4756警告都关掉包括那些真正有价值的、指向你自己代码里常量溢出的警告。我就遇到过这样的情况全局禁用之后项目里一个真正的数值计算bug被掩盖了直到运行时才发现结果不对排查了半天才想起来是当初把警告关了。提示如果你决定用这个方案至少要在代码审查清单里加一条——定期用不禁用警告的配置编译一次检查是否有非INFINITY相关的C4756。4.2 方案二精准抑制特定头文件的警告更精细的做法是用#pragma warning(push/pop)把警告抑制限定在特定范围内#pragma warning(push) #pragma warning(disable:4756) #include math.h #pragma warning(pop)但问题是INFINITY宏的使用往往分散在大量头文件和源文件里你很难精确控制每一个包含点。而且UE的构建系统会自动生成大量的包含关系手动加pragma的工作量巨大且容易遗漏。4.3 方案三通过构建系统把相关路径标记为系统头文件这是我认为最优雅的方案。MSVC支持/external:I选项来指定外部头文件路径配合/external:W0可以把这些路径下的所有警告降到0级/external:IC:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt /external:W0在UE的构建系统里可以通过修改BuildConfiguration.xml或者模块的Build.cs文件来添加这些选项。具体来说在Build.cs里可以这样写PublicSystemIncludePaths.Add(C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.22621.0\\ucrt);然后在Target.cs里确保bEnableUndefinedIdentifierWarnings之类的选项配置正确。这个方案的优点是精准——只抑制系统头文件里的警告你自己代码里的C4756依然会报出来。缺点是需要对UE的构建系统有一定了解而且不同版本的Windows SDK路径不一样需要根据实际情况调整。4.4 方案四升级MSVC工具集或Windows SDK如果你有升级的灵活性把MSVC工具集升到VS2022 17.7或者把Windows SDK升到较新的版本部分场景下的C4756会自动消失。但UE5.2对工具集版本有要求不是所有版本都能直接用。而且升级工具集可能会引入新的编译问题需要做完整的回归测试。4.5 四种方案的对比与选择建议方案工作量精准度风险适用场景全局禁用极低低高掩盖真实问题临时应急快速出包精准pragma中中中容易遗漏少量特定文件系统头文件标记中高高低长期维护的项目升级工具集高高中可能引入新问题有升级计划的项目我的建议是如果是短期应急先用全局禁用把包出出来如果是长期维护的项目花时间把系统头文件标记配好一劳永逸。升级工具集这件事最好跟着引擎版本的升级节奏走不要单独升。5. 实操在UE5.2项目里落地系统头文件标记方案5.1 确认当前使用的Windows SDK版本第一步是搞清楚你的项目到底在用哪个版本的Windows SDK。最直接的方法是看编译日志里的包含路径搜索Windows Kits关键字就能看到类似这样的路径C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um记下这个版本号比如10.0.22621.0后面配置的时候要用到。5.2 修改模块的Build.cs文件找到你项目里需要处理的模块打开对应的Build.cs文件。在构造函数里添加系统包含路径public class MyProject : ModuleRules { public MyProject(ReadOnlyTargetRules Target) : base(Target) { // 其他配置... string WindowsSdkVersion 10.0.22621.0; string WindowsSdkBase C:\Program Files (x86)\Windows Kits\10\Include\ WindowsSdkVersion; PublicSystemIncludePaths.Add(WindowsSdkBase \ucrt); PublicSystemIncludePaths.Add(WindowsSdkBase \shared); PublicSystemIncludePaths.Add(WindowsSdkBase \um); } }注意这里用的是PublicSystemIncludePaths而不是PublicIncludePaths。这个区别很关键——只有SystemIncludePaths才会被UE的构建系统转换为MSVC的/external:I选项从而触发警告抑制。5.3 验证配置是否生效改完之后重新生成项目文件然后编译。在编译日志里搜索/external:I应该能看到你添加的路径。同时观察C4756警告的数量是否明显下降。如果警告数量没有变化可能是以下几个原因一是路径写错了二是UE的构建系统版本不支持PublicSystemIncludePaths三是警告来自其他没有被标记的路径。需要逐一排查。5.4 处理第三方库的包含路径很多C4756警告其实来自第三方库引入的头文件。对于这些库你需要把它们的包含路径也加到PublicSystemIncludePaths里。但要注意不是所有第三方库都适合这么做——如果某个库的头文件里确实有你自己代码需要关注的警告把它标记为系统头文件就会把这些警告也抑制掉。我的做法是先只标记Windows SDK的路径编译一次看还剩多少警告。如果剩下的警告主要集中在某几个第三方库再针对性地处理。不要一上来就把所有路径都标记为系统头文件那样会失去警告的价值。6. 那些文档里不会写的踩坑经验6.1 警告数量突然翻倍可能是包含顺序问题有一次我改完配置后发现C4756警告不但没减少反而从800条涨到了1600条。排查了半天才发现是因为我在Build.cs里添加系统包含路径时不小心改变了头文件的搜索顺序导致某些头文件被重复包含INFINITY宏被展开了两次。MSVC的头文件包含是有顺序依赖的。PublicSystemIncludePaths里的路径会被插入到包含路径列表的特定位置如果插入位置不对可能会改变原有的包含顺序。解决办法是尽量把系统路径放在列表末尾或者用PublicIncludePaths和PublicSystemIncludePaths配合使用确保顺序正确。6.2 不同模块的配置不能互相覆盖UE的构建系统里每个模块的Build.cs是独立配置的。你在A模块里加了系统包含路径不会自动应用到B模块。如果项目里有几十个模块逐个添加工作量很大。一个取巧的做法是在项目的Target.cs里统一配置但Target.cs的配置粒度比较粗不能针对单个模块做精细控制。我的建议是写一个公共的辅助函数在各个模块的Build.cs里调用public static void AddWindowsSdkSystemPaths(ModuleRules Rules) { string SdkVersion 10.0.22621.0; string Base C:\Program Files (x86)\Windows Kits\10\Include\ SdkVersion; Rules.PublicSystemIncludePaths.Add(Base \ucrt); Rules.PublicSystemIncludePaths.Add(Base \shared); Rules.PublicSystemIncludePaths.Add(Base \um); }然后在每个模块里调用这个函数。这样既统一了配置又保留了模块级的灵活性。6.3 增量编译和全量编译的警告数量不一样这是一个很容易让人困惑的现象增量编译时可能只报几十条C4756全量编译时却报上千条。原因是增量编译只重新编译修改过的文件而很多包含INFINITY的头文件在增量编译时没有被重新处理。所以验证配置效果时一定要做一次全量编译先Clean再Build否则你看到的警告数量是不准确的。我一开始就被这个现象误导过以为配置生效了结果全量编译后发现警告数量根本没变。6.4 某些警告来自引擎源码而非你的项目UE5.2的引擎源码里也有一些地方会触发C4756。这些警告你没法通过修改自己项目的Build.cs来消除因为引擎模块的构建配置是独立的。对于这种情况要么等引擎官方修复要么在引擎源码的对应模块里做同样的系统头文件标记。但修改引擎源码意味着你维护了一份非标准的引擎分支后续升级会比较麻烦。我的做法是引擎源码里的C4756警告就让它报着只要不影响编译结果在日志过滤的时候忽略掉就行。6.5 注意区分C4756和其他类似警告MSVC还有几个和C4756长得很像的警告比如C4305截断、C4309常量截断、C4756常量算术溢出。它们的触发条件不同处理方式也不一样。在排查的时候要注意看警告编号不要混为一谈。特别是C4305它经常和C4756一起出现因为INFINITY宏展开后的表达式在转换为float时可能同时触发这两个警告。处理的时候要一起考虑。7. 从C4756看MSVC与MinGW的深层差异7.1 标准库实现哲学的差异C4756这个问题的根源其实是MSVC和GCC/Clang在标准库实现哲学上的差异。MSVC倾向于用纯C的常量表达式来实现标准库宏这样不依赖编译器内置功能理论上可移植性更好。但代价是在某些场景下会产生编译器警告。GCC和Clang则更倾向于使用编译器内置功能实现更简洁编译行为也更干净。但代价是这些内置功能不是标准C的一部分换一个编译器就用不了。这两种哲学没有绝对的对错但在实际项目中会产生完全不同的体验。UE5.2在Windows平台上默认用MSVC所以就撞上了C4756这个问题。7.2 对构建系统的影响这个差异还会影响构建系统的设计。UE的构建系统需要同时支持MSVC、Clang、GCC等多种编译器所以它不能假设所有编译器都有__builtin_inff()这样的内置功能。这就导致UE在处理INFINITY相关的警告时只能采用比较通用的方式而无法针对MSVC做特殊优化。如果你在项目里同时维护Windows和Linux版本就会发现Linux版本用Clang或GCC完全没有C4756的问题而Windows版本需要额外处理。这种平台差异在跨平台项目里很常见关键是要有一套统一的构建配置管理方案。7.3 实际项目中的选择建议如果你的项目主要在Windows上开发用MSVC是默认选择那就老老实实处理C4756。如果你的项目需要跨平台可以考虑在Windows上也用ClangUE支持Clang on Windows这样就能避开C4756但可能会遇到其他兼容性问题。MinGW在UE项目里用得比较少主要是因为UE的构建系统对MinGW的支持不如MSVC和Clang完善。如果你只是编译一些独立的C/C库MinGW是个不错的选择但如果是完整的UE项目还是建议用MSVC或Clang。8. 我个人的处理策略与后续建议经过几个项目的实践我现在的处理策略是这样的首先在项目初期就把Windows SDK的系统包含路径配好不要等到警告堆积如山了再处理。其次对于引擎源码里的C4756在日志过滤规则里加一条忽略规则不要让它们干扰真正需要关注的警告。最后定期用不抑制警告的配置做一次全量编译检查是否有非INFINITY相关的C4756被遗漏了。还有一个小技巧在CI流水线里加一个警告数量统计的步骤如果C4756的数量突然大幅增加说明可能有新的代码或库引入了问题可以及时发现。这个统计不需要很精确大概的数量级变化就足够引起注意了。另外如果你在升级UE版本建议在升级前先记录当前版本的C4756警告数量升级后再对比。如果数量没有明显变化说明新版本没有引入新的问题如果数量激增就需要排查是哪个模块或库导致的。这个对比数据在排查问题时非常有用。最后说一句关于INFINITY宏本身的使用建议在UE项目里尽量用UE自己提供的数学常量比如TNumericLimitsfloat::Max()或者UE_INFINITY之类的封装而不是直接用标准C的INFINITY宏。这样既能避开C4756又能保持代码风格的一致性。UE的数学库已经对这些常量做了很好的封装直接用就行没必要跟标准库的宏较劲。