0b二进制字面量配合'分隔符能直观映射寄存器每位功能，如0b1010'0101直接对应spec手册bit图，而0xA5需人工拆解且无法体现字段逻辑；'仅允许在数字间使用，赋值给char有符号溢出风险，应优先用uint8_t；GCC 4.9+/Clang 3.4+/MSVC 19.0+支持，但需显式启用C++14标准。
直接用 0b 写二进制、用 ' 分隔数字，比手动换算成十六进制或十进制更贴近硬件意图，也更少出错。
为什么 0b1010'0101 比 0xA5 更适合寄存器配置
寄存器每一位常对应特定功能（如 bit0 是使能、bit7 是中断标志），用二进制字面量能一眼看出哪些位被置 1。十六进制虽然紧凑，但需 mentally 拆解每半字节——0xA5 是 1010'0101，但人眼不会自动分组；而 0b1010'0101 已经强制按语义边界对齐。
-
0b1010'0101中的'可以放在你认为逻辑分界的位置，比如0b10'1001'01表示“2-bit mode + 4-bit config + 2-bit status” -
0xA5无法体现这种字段划分，除非加注释，但注释易过期 - 调试时看内存 dump，十六进制输出是主流，但源码里用二进制写，能更快和 spec 手册里的 bit diagram 对齐
' 分隔符在不同进制下的合法位置和常见误用
' 是纯视觉符号，编译器完全忽略，但它有硬性语法限制：只能插在两个数字字符之间，不能挨着前缀、小数点、指数符号或结尾。
- ✅ 合法：
0b1111'0000、0xFF'80'40、1'000'000、3.1415'9265 - ❌ 非法：
0b'1111'0000（开头单引号）、0b1111'0000'（结尾单引号）、0b1111 0000（空格，不是'） - ⚠️ 易错：写成
int x = flag_0b1010'1010;—— 这里'在变量名里，不构成字面量，编译器报错或静默忽略，结果不是你想要的值
类型推导与溢出风险：为什么 char c = 0b1000'0000 很危险
二进制字面量本身是整型字面量，默认类型是 int（至少 16 位），但赋值给窄类型时会隐式转换。问题在于符号扩展和平台定义行为。
立即学习“C++免费学习笔记（深入）”；
-
char在多数平台是有符号的，0b1000'0000是 128，超出char的正数范围（通常 -128~127），触发实现定义行为 -
uint8_t是安全选择：uint8_t flag = 0b1000'0000;明确无符号且宽度固定 -
constexpr auto推导出的是int，若后续用于模板参数（如std::array<int, N>），N 必须是编译期常量，而int值本身没问题，但类型宽度可能影响 ABI 兼容性
跨编译器兼容性底线：哪些版本真能用
不是所有标称支持 C++14 的编译器都默认启用这些特性，尤其在嵌入式或旧构建链中。
- GCC 4.9+ 和 Clang 3.4+ 支持
0b和'，但需显式指定标准：-std=c++14或更高；-std=gnu++14也可，但避免依赖 GNU 扩展 - MSVC 从 19.0（VS2015 Update 3）起完整支持，早期版本（如 VS2015 RTM）只部分支持，
'可能报错 - 嵌入式工具链（如 ARM GCC 6.3）通常没问题，但某些裁剪版 Newlib 或裸机环境可能禁用 C++14 特性，需验证
__cplusplus宏值是否为201402L - CI/CD 流水线里最容易漏掉的是 CMake 的
set(CMAKE_CXX_STANDARD 14)，否则即使编译器支持，也会退回到 C++98 模式
真正难的不是记住语法，而是习惯把字段边界、字节对齐、协议规范这些信息直接编码进字面量本身——而不是靠注释或外部文档。一旦养成这个习惯，别人读你的寄存器配置代码，就不再需要查表换算。
