回调函数约定宏
回调函数约定宏的常见场景
IRC_NET_CALL在 Linux/macOS/Android/Posix 类系统 下被定义为空宏，这是 SDK 针对不同操作系统做的跨平台兼容设计，不强制指定任何函数调用约定，完全使用编译器的默认调用约定（GCC/Clang 下默认是 __cdecl）
为什么 Linux 下不需要显式定义 IRC_NET_CALL
1. Linux 下调用约定的 “大一统”
Windows下有多种调用约定（__stdcall/__cdecl/__fastcall），且系统 API、驱动、第三方 SDK 常强制要求__stdcall，因此需要 IRC_NET_CALL 显式指定；
Linux/Posix 系统下，GCC/Clang 编译器默认的__cdecl（也叫 gcc 调用约定）是唯一通用的调用约定，所有 C/C++ 代码默认遵循该规则：
参数从右到左压栈；
调用者负责清理栈；
函数名修饰规则统一（无 Windows 的_stdcall@8这类后缀）。
因此 SDK 底层（libIRCNetSDK.so）和你的回调函数，默认就是同一套调用约定，无需显式指定。
Linux 下的动态库（.so）调用函数时，是通过函数地址（指针）直接调用，只要函数签名（返回值、参数列表）一致，调用约定默认匹配，不会出现 Windows 下的 “调用约定不匹配导致崩溃” 的问题。
虽然 Linux 下是空宏，但 SDK 仍要求你在回调函数上写 IRC_NET_CALL，核心原因是跨平台兼容性，同一套代码可以无缝编译到 Windows/Linux/Android 等系统。
| 核心维度 | __cdecl（C 声明约定） | __stdcall（标准调用约定） | __fastcall（快速调用约定） |
|---|---|---|---|
| 参数传递 | 所有参数从右到左压栈 | 所有参数从右到左压栈 | 前 2 个整型参数入 ECX/EDX 寄存器，剩余参数从右到左压栈 |
| 栈清理责任 | 调用者（Caller）清理栈 | 被调用者（Callee）清理栈 | 被调用者（Callee）清理栈 |
| 函数名修饰 | GCC：原名称MSVC：前缀下划线（如_func） | GCC：原名称MSVC：_名称 @字节数（如_func@8） | GCC：@名称 @字节数MSVC：@名称 @字节数（如@func@8） |
| 可变参数支持 | 支持（如printf） | 不支持（参数数量固定） | 不支持（寄存器传参适配性差） |
| 默认适配 | Linux/GCC 全局默认Windows/MSVC 局部默认 | Windows API / 多数 DLL 默认 | 无默认场景，需显式指定 |
| 性能 | 普通（全栈操作） | 普通（全栈操作） | 更高（寄存器减少栈交互） |
| 跨平台兼容性 | 全平台兼容（Linux/Windows/macOS） | 仅 Windows 主流，Linux 几乎不用 | 编译器 / 平台兼容差（慎用） |
| 崩溃风险 | 低（调用者可控栈清理） | 中（参数数错则栈崩溃） | 中（同__stdcall + 寄存器适配风险） |
Linux/ARM（lubancat）场景：
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) → _Z4funci
void func(float) → _Z4funcf
不同编译器（GCC/MSVC/Clang）的粉碎规则不同，但核心逻辑是 “将函数特征编码为字符串”，GCC 的规则（Itanium C++ ABI 标准）可拆解为：
_Z + <函数名长度><函数名> + <参数类型编码>| 原始函数 | GCC 粉碎后符号名 | 编码拆解 |
|---|---|---|
void func(int) | _Z4funci | _Z（固定前缀）+4（func 长度）+func +i（int） |
void func(float) | _Z4funcf | _Z +4 +func +f（float） |
class A { void func(); } | _ZN1A4funcEv | _Z +N（类标记）+1（A 长度）+A +4 +func +v（void） |
namespace NS { void func(double); } | _ZN2NS4funcd | _Z +N（命名空间）+2（NS 长度）+NS +4 +func +d（double） |
MSVC 的粉碎规则不同（比如 void func(int) → ?func@@YAXH@Z），但核心逻辑一致：编码函数名 + 参数 + 作用域。
当你在 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 // SDK（C 编写）导出的符号是 `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.cpp（GCC编译为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.cpp（MSVC编译） #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 回调函数通常设计为全局函数（而非类成员）。