为何代码‘int a = 0xe+1’无法编译？哪个编译器合规？

首先直接给出结论：Clang、GCC、ICC的处理完全符合C/C++标准，MSVC的编译通过属于非标准的扩展行为。

为什么Clang/GCC/ICC会报错？ #

我们得从C/C++标准定义的整数常量语法说起：

• 十六进制整数常量的格式是：0x/0X开头，后跟一串十六进制数字（0-9、a-f/A-F），最后可搭配标准规定的类型后缀（比如u/U表示无符号、l/L表示长整型、ll/LL表示长长整型）。
• + 根本不在标准允许的整数常量后缀列表里！

当编译器解析0xe+1时，会先把0xe识别为十六进制整数，紧接着的+会被当作尝试匹配整数后缀，但因为+是非法后缀，所以直接抛出invalid suffix '+' on integer constant的错误。

为什么这两种修改能让代码正常编译？ #

1. 在+前添加空格

改成0xe + 1后，编译器会把0xe识别为独立的十六进制整数常量，+则被解析为加法运算符，整个表达式变成14 + 1的算术运算，完全符合语法规则，自然能顺利编译。

2. 将0xe改为0xf

这里确实和浮点数的指数表示（比如1.2e+3）有间接关联，但得理清逻辑：

• 浮点数的十进制指数用e/E标记，但十六进制浮点数的指数标记是p/P（比如0x1.ep+3表示(1 + 14/16) * 2^3），所以0xe本身是纯十六进制整数，不会被当成浮点数开头。
• 那0xf+1能编译的原因是：编译器解析到0xf时，f是合法十六进制数字，后面的+不是合法后缀，所以会立刻结束整数常量的解析，把0xf作为完整整数，再把+1识别为加法操作。
• 而0xe+1的问题在于，编译器会严格按照整数常量语法检查后缀：0xe后的+被当作后缀尝试匹配，而+不在合法后缀列表里，因此报错——这里的核心是语法解析的优先级，编译器不会跳过非法后缀去解析后面的加法，而是直接触发语法错误。

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