在C、Rust、C++中使用下划线‘_’作为标识符的注意事项与互操作性问题

• 标准合法性：C标准仅保留以下划线开头且后续紧跟大写字母或另一个下划线的标识符（如_Foo、__bar），以及文件作用域内以下划线开头的标识符。词法局部作用域的单独_并未被标准保留，属于合法的用户可用标识符。
• 编译器与扩展风险：部分编译器的调试或内置机制可能在局部作用域隐含使用_（尽管极少），需测试目标编译器（如GCC、Clang、MSVC）是否存在冲突。另外，若你的宏展开后生成_作为临时变量，要避免与用户代码中自行定义的_变量重名，引发编译错误。
• 可读性与惯用冲突：C社区中_通常用作“丢弃变量”（如(void)_ = some_func();）来规避未使用变量警告。若你的库将_用作特殊语义（如指代上一表达式值），需在文档中明确说明，避免其他开发者误解为可忽略的变量。
• 宏设计约束：如果用宏封装_的逻辑，需确保宏的作用域隔离，比如用do { ... } while(0)包裹宏体，防止_变量泄漏到外部作用域，与用户代码的_产生冲突。

C++ #

• C标准对_的保留规则与C类似，但社区惯用场景更多：结构化绑定中auto [_, val] = pair;是忽略元素的标准写法，Lambda表达式或模板中也常出现_作为占位符。若你的C库提供C绑定并使用_做特殊用途，会与这些惯用逻辑冲突，降低代码可读性。
• 部分C++编译器的扩展可能在局部作用域使用_，需验证目标编译环境的兼容性。

Rust #

• Rust中_是语法级别的占位符，而非合法标识符：它仅用于忽略值（如let _ = get_value();）或模式匹配中的通配符，无法被当作普通变量使用。因此，若你的C库要与Rust交互，不能依赖_作为可访问的标识符，Rust绑定会直接报错。

• 跨语言绑定障碍：如Rust的情况，_在Rust中是语法符号，无法映射为合法变量；C++中则会与惯用写法冲突，增加绑定代码的维护成本。
• 第三方库冲突：若用户代码中引入其他使用_作为局部变量的库，会导致重复定义编译错误，尤其是当你的宏展开后生成_变量时，冲突概率更高。
• 工具链误判：静态分析工具（如clang-tidy）、代码格式化工具通常将_视为丢弃变量，若你的库中_被实际使用，可能触发误报警告，干扰代码检查流程。
• 团队协作成本：不熟悉你的库语义的开发者，可能误将_当作可忽略的变量，修改代码时破坏原有逻辑，增加维护难度。

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