酷站海洛劳务建筑公司网站

酷站海洛,劳务建筑公司网站,国家专利网查询入口,国外风格网站回调函数约定宏的常见场景自己写的头文件#xff0c;需要有IRC_NET_CALL这个回调约定宏这个回调约定宏在 Linux/macOS/Android/Posix 类系统 下被定义为空宏IRC_NET_CALL 在 Linux/macOS/Android/Posix 类系统 下被定义为空宏#xff0c;这是 SDK 针对不同操作系统做的跨平台…回调函数约定宏的常见场景自己写的头文件需要有IRC_NET_CALL这个回调约定宏这个回调约定宏在 Linux/macOS/Android/Posix 类系统 下被定义为空宏IRC_NET_CALL在 Linux/macOS/Android/Posix 类系统 下被定义为空宏这是 SDK 针对不同操作系统做的跨平台兼容设计不强制指定任何函数调用约定完全使用编译器的默认调用约定GCC/Clang 下默认是 __cdecl为什么 Linux 下不需要显式定义 IRC_NET_CALL1. Linux 下调用约定的 “大一统”Windows下有多种调用约定__stdcall/__cdecl/__fastcall且系统 API、驱动、第三方 SDK 常强制要求__stdcall因此需要 IRC_NET_CALL 显式指定Linux/Posix 系统下GCC/Clang 编译器默认的__cdecl也叫 gcc 调用约定是唯一通用的调用约定所有 C/C 代码默认遵循该规则参数从右到左压栈调用者负责清理栈函数名修饰规则统一无 Windows 的_stdcall8这类后缀。因此 SDK 底层libIRCNetSDK.so和你的回调函数默认就是同一套调用约定无需显式指定。Linux 下的动态库.so调用函数时是通过函数地址指针直接调用只要函数签名返回值、参数列表一致调用约定默认匹配不会出现 Windows 下的 “调用约定不匹配导致崩溃” 的问题。虽然 Linux 下是空宏但 SDK 仍要求你在回调函数上写 IRC_NET_CALL核心原因是跨平台兼容性同一套代码可以无缝编译到 Windows/Linux/Android 等系统。核心维度__cdeclC 声明约定__stdcall标准调用约定__fastcall快速调用约定参数传递所有参数从右到左压栈所有参数从右到左压栈前 2 个整型参数入 ECX/EDX 寄存器剩余参数从右到左压栈栈清理责任调用者Caller清理栈被调用者Callee清理栈被调用者Callee清理栈函数名修饰GCC原名称MSVC前缀下划线如_funcGCC原名称MSVC_名称 字节数如_func8GCC名称 字节数MSVC名称 字节数如func8可变参数支持支持如printf不支持参数数量固定不支持寄存器传参适配性差默认适配Linux/GCC 全局默认Windows/MSVC 局部默认Windows API / 多数 DLL 默认无默认场景需显式指定性能普通全栈操作普通全栈操作更高寄存器减少栈交互跨平台兼容性全平台兼容Linux/Windows/macOS仅 Windows 主流Linux 几乎不用编译器 / 平台兼容差慎用崩溃风险低调用者可控栈清理中参数数错则栈崩溃中同__stdcall 寄存器适配风险Linux/ARMlubancat场景GCC 默认用 __cdecl且 __stdcall/__fastcall 几乎无实际意义系统 / 动态库均遵循 __cdecl 逻辑因此 SDK 中 IRC_NET_CALL 定义为空宏即可Windows 场景系统 API、DLL 导出函数如 SDK 回调几乎都用 __stdcall漏加会导致参数错位 / 栈崩溃工程避坑可变参数函数如 log(...)只能用 __cdecl回调函数必须严格匹配 SDK 约定尤其是 Windows跨平台代码优先用 SDK 封装的宏如 IRC_NET_CALL避免直接写 __stdcall 等硬编码。extern c 函数名的用法extern C 是 C 特有的和 IRC_NET_CALL 配合extern C保证函数名按 C 规则修饰避免 C 的名字粉碎IRC_NET_CALL 保证调用规则匹配。c函数名称粉碎名字粉碎也叫 “名字修饰”是 C 编译器为了解决「函数重载、命名空间、类成员函数」等特性带来的 “同名函数区分问题”对函数名进行的编码转换——编译器会将函数的原始名、参数类型、命名空间、类名等信息编码到最终的函数名中生成唯一的 “粉碎名”确保链接器能精准找到对应的函数实现。C 语言没有名字粉碎函数名就是最终符号名而 C 因面向对象特性必须依赖该机制这也是为什么你代码中回调函数要加 extern C 来禁用粉碎。C 支持函数重载同名函数不同参数但链接器是 “无类型” 的 —— 它只认符号名若不做粉碎会无法区分重载函数。// 重载函数 void func(int); void func(float);如果不做名字粉碎链接器看到两个 func 会认为是重复定义而经过粉碎后编译器会生成两个完全不同的符号名比如 GCC 下void func(int) → _Z4funcivoid func(float) → _Z4funcf不同编译器GCC/MSVC/Clang的粉碎规则不同但核心逻辑是 “将函数特征编码为字符串”GCC 的规则Itanium C ABI 标准可拆解为_Z 函数名长度函数名 参数类型编码原始函数GCC 粉碎后符号名编码拆解void func(int)_Z4funci_Z固定前缀4func 长度func iintvoid func(float)_Z4funcf_Z 4 func ffloatclass A { void func(); }_ZN1A4funcEv_Z N类标记1A 长度A 4 func vvoidnamespace NS { void func(double); }_ZN2NS4funcd_Z N命名空间2NS 长度NS 4 func ddoubleMSVC 的粉碎规则不同比如 void func(int) → ?funcYAXHZ但核心逻辑一致编码函数名 参数 作用域。当你在 C 代码中调用 C 语言编写的 SDK如 libIRCNetSDK.so时必须用 extern C 告诉编译器该函数按 C 语言规则编译禁用名字粉碎。// 1. 无 extern C → 触发名字粉碎 void IRC_NET_CALL ExceptionCallback(IRC_NET_HANDLE handle, int type); // GCC 粉碎后_Z20ExceptionCallback18IRC_NET_HANDLEi // SDKC 编写导出的符号是 ExceptionCallback → 链接器找不到报“未定义引用” // 2. 加 extern C → 禁用粉碎按 C 规则生成符号 extern C void IRC_NET_CALL ExceptionCallback(IRC_NET_HANDLE handle, int type); // 编译后符号名ExceptionCallback → 和 C 编写的 SDK 导出符号一致链接成功C 调用 C 库未加 extern C现象链接时报 undefined reference to _Z20ExceptionCallback...原因是 C 粉碎了函数名而 C 库导出的是原始名改造 C 库GCC 编译用extern C暴露接口禁用名字粉碎// test_lib.cppGCC编译为libtest.so #ifdef __cplusplus // 仅在C编译环境生效 extern C { // 开启C语言编译规则 #endif // 封装的接口禁用名字粉碎仅暴露原始名func void func(int a, float b) { // 内部可写任意C逻辑类、重载、STL等 // 对外只暴露C风格接口 } #ifdef __cplusplus } // 关闭extern C #endifMSVC 调用该库Windows按 C 规则链接// main.cppMSVC编译 #ifdef __cplusplus extern C { // 告诉MSVC按C规则查找符号func #endif // 声明接口和库中一致 void func(int a, float b); #ifdef __cplusplus } #endif int main() { func(10, 3.14f); // MSVC按原始名func查找匹配GCC库的导出符号 return 0; }工业级写法// 头文件test_lib.h供调用方包含 #ifndef TEST_LIB_H #define TEST_LIB_H // 定义跨编译器的C接口宏 #ifdef __cplusplus #define EXTERN_C extern C #else #define EXTERN_C #endif // 暴露C风格接口 EXTERN_C void func(int a, float b); #endif跨编译器 / 平台的粉碎规则不兼容比如 GCC 编译的 C 库MSVC 调用时会因粉碎规则不同导致链接失败解决方案是用 extern C 封装接口类成员函数无法禁用粉碎类成员函数包括虚函数即使加 extern C 也无效因为要编码 this 指针、类名因此 SDK 回调函数通常设计为全局函数而非类成员。