维护兼容旧编译器的C++库时，直接定义未被支持的noexcept关键字是否符合规范？

首先明确结论：从C++标准的严格定义来看，这种做法确实是违规的。C++标准明确规定，程序不得将语言的标准关键字（比如noexcept）定义为宏，这属于标准范畴内的未定义行为——简单来说，标准不保证这么做会有什么结果，理论上可能触发各种不可预期的问题。

但回到你的实际场景：针对VC2013这种**已经停止维护、仅部分支持C11**的旧编译器，这种做法在工程实践中其实处于“灰色地带”，而且被很多项目验证过是可行的。

具体分析： #

• 标准层面的违规点：C标准把noexcept列为保留关键字，任何试图通过宏重定义它的行为，都违反了标准中关于“不得宏定义保留标识符”的规则。如果你的代码需要严格符合C标准（比如要通过某些合规性检查），这种做法肯定不达标。
• 实际工程中的可行性：VC++2013本身根本没有实现noexcept关键字的支持——它既不认识这个词，也不会处理任何和noexcept相关的语义。当你把noexcept宏定义为空时，编译器只会把代码里的noexcept当作空白忽略，完全不会触发任何冲突或异常逻辑。在这种特定场景下，几乎不会出现实际问题。

两种方案的对比： #

• 自定义宏（比如NOEXCEPT）方案：
  • 优点：完全符合标准，不会污染关键字空间，代码中的宏标识清晰，一眼就能看出是兼容处理；未来如果要兼容其他行为差异更大的编译器，扩展起来更灵活。
  • 缺点：需要修改所有原本要写noexcept的地方，代码中会大量出现自定义宏，破坏了标准C++11的写法一致性。
• 直接#define noexcept方案：
  • 优点：代码风格完全和标准C11一致，不需要修改大量代码，可读性更好；针对VC2013这种固定的旧编译器，几乎不会有实际风险。
  • 缺点：严格违反标准，若未来有意外情况（比如VC2013的某个非官方补丁突然支持了noexcept），可能会导致编译冲突——不过考虑到VC2013已经停止更新多年，这种可能性极低。

个人建议： #

如果你的库只需要兼容VC++2013这一个不支持noexcept的旧编译器，而且团队可以接受这种“工程妥协”，那么直接#define noexcept是完全可行的，很多跨平台开源库在兼容旧编译器时都采用过这种方式。但如果你的项目需要严格遵循标准，或者未来可能兼容更多旧编译器，那还是用自定义宏的方式更稳妥。

内容的提问来源于stack exchange，提问作者Luigi Ballabio