東莞土木建筑學會網(wǎng)站,鄂州正規(guī)網(wǎng)站建設,2017最新網(wǎng)站icp備案,平臺網(wǎng)站怎么建設回調(diào)函數(shù)約定宏的常見場景自己寫的頭文件#xff0c;需要有IRC_NET_CALL這個回調(diào)約定宏這個回調(diào)約定宏在 Linux/macOS/Android/Posix 類系統(tǒng) 下被定義為空宏IRC_NET_CALL 在 Linux/macOS/Android/Posix 類系統(tǒng) 下被定義為空宏#xff0c;這是 SDK 針對不同操作系統(tǒng)做的跨平臺…回調(diào)函數(shù)約定宏的常見場景自己寫的頭文件需要有IRC_NET_CALL這個回調(diào)約定宏這個回調(diào)約定宏在 Linux/macOS/Android/Posix 類系統(tǒng) 下被定義為空宏IRC_NET_CALL在 Linux/macOS/Android/Posix 類系統(tǒng) 下被定義為空宏這是 SDK 針對不同操作系統(tǒng)做的跨平臺兼容設計不強制指定任何函數(shù)調(diào)用約定完全使用編譯器的默認調(diào)用約定GCC/Clang 下默認是 __cdecl為什么 Linux 下不需要顯式定義 IRC_NET_CALL1. Linux 下調(diào)用約定的 “大一統(tǒng)”Windows下有多種調(diào)用約定__stdcall/__cdecl/__fastcall且系統(tǒng) API、驅動、第三方 SDK 常強制要求__stdcall因此需要 IRC_NET_CALL 顯式指定Linux/Posix 系統(tǒng)下GCC/Clang 編譯器默認的__cdecl也叫 gcc 調(diào)用約定是唯一通用的調(diào)用約定所有 C/C 代碼默認遵循該規(guī)則參數(shù)從右到左壓棧調(diào)用者負責清理棧函數(shù)名修飾規(guī)則統(tǒng)一無 Windows 的_stdcall8這類后綴。因此 SDK 底層libIRCNetSDK.so和你的回調(diào)函數(shù)默認就是同一套調(diào)用約定無需顯式指定。Linux 下的動態(tài)庫.so調(diào)用函數(shù)時是通過函數(shù)地址指針直接調(diào)用只要函數(shù)簽名返回值、參數(shù)列表一致調(diào)用約定默認匹配不會出現(xiàn) Windows 下的 “調(diào)用約定不匹配導致崩潰” 的問題。雖然 Linux 下是空宏但 SDK 仍要求你在回調(diào)函數(shù)上寫 IRC_NET_CALL核心原因是跨平臺兼容性同一套代碼可以無縫編譯到 Windows/Linux/Android 等系統(tǒng)。核心維度__cdeclC 聲明約定__stdcall標準調(diào)用約定__fastcall快速調(diào)用約定參數(shù)傳遞所有參數(shù)從右到左壓棧所有參數(shù)從右到左壓棧前 2 個整型參數(shù)入 ECX/EDX 寄存器剩余參數(shù)從右到左壓棧棧清理責任調(diào)用者Caller清理棧被調(diào)用者Callee清理棧被調(diào)用者Callee清理棧函數(shù)名修飾GCC原名稱MSVC前綴下劃線如_funcGCC原名稱MSVC_名稱 字節(jié)數(shù)如_func8GCC名稱 字節(jié)數(shù)MSVC名稱 字節(jié)數(shù)如func8可變參數(shù)支持支持如printf不支持參數(shù)數(shù)量固定不支持寄存器傳參適配性差默認適配Linux/GCC 全局默認Windows/MSVC 局部默認Windows API / 多數(shù) DLL 默認無默認場景需顯式指定性能普通全棧操作普通全棧操作更高寄存器減少棧交互跨平臺兼容性全平臺兼容Linux/Windows/macOS僅 Windows 主流Linux 幾乎不用編譯器 / 平臺兼容差慎用崩潰風險低調(diào)用者可控棧清理中參數(shù)數(shù)錯則棧崩潰中同__stdcall 寄存器適配風險Linux/ARMlubancat場景GCC 默認用 __cdecl且 __stdcall/__fastcall 幾乎無實際意義系統(tǒng) / 動態(tài)庫均遵循 __cdecl 邏輯因此 SDK 中 IRC_NET_CALL 定義為空宏即可Windows 場景系統(tǒng) API、DLL 導出函數(shù)如 SDK 回調(diào)幾乎都用 __stdcall漏加會導致參數(shù)錯位 / 棧崩潰工程避坑可變參數(shù)函數(shù)如 log(...)只能用 __cdecl回調(diào)函數(shù)必須嚴格匹配 SDK 約定尤其是 Windows跨平臺代碼優(yōu)先用 SDK 封裝的宏如 IRC_NET_CALL避免直接寫 __stdcall 等硬編碼。extern c 函數(shù)名的用法extern C 是 C 特有的和 IRC_NET_CALL 配合extern C保證函數(shù)名按 C 規(guī)則修飾避免 C 的名字粉碎IRC_NET_CALL 保證調(diào)用規(guī)則匹配。c函數(shù)名稱粉碎名字粉碎也叫 “名字修飾”是 C 編譯器為了解決「函數(shù)重載、命名空間、類成員函數(shù)」等特性帶來的 “同名函數(shù)區(qū)分問題”對函數(shù)名進行的編碼轉換——編譯器會將函數(shù)的原始名、參數(shù)類型、命名空間、類名等信息編碼到最終的函數(shù)名中生成唯一的 “粉碎名”確保鏈接器能精準找到對應的函數(shù)實現(xiàn)。C 語言沒有名字粉碎函數(shù)名就是最終符號名而 C 因面向對象特性必須依賴該機制這也是為什么你代碼中回調(diào)函數(shù)要加 extern C 來禁用粉碎。C 支持函數(shù)重載同名函數(shù)不同參數(shù)但鏈接器是 “無類型” 的 —— 它只認符號名若不做粉碎會無法區(qū)分重載函數(shù)。// 重載函數(shù) void func(int); void func(float);如果不做名字粉碎鏈接器看到兩個 func 會認為是重復定義而經(jīng)過粉碎后編譯器會生成兩個完全不同的符號名比如 GCC 下void func(int) → _Z4funcivoid func(float) → _Z4funcf不同編譯器GCC/MSVC/Clang的粉碎規(guī)則不同但核心邏輯是 “將函數(shù)特征編碼為字符串”GCC 的規(guī)則Itanium C ABI 標準可拆解為_Z 函數(shù)名長度函數(shù)名 參數(shù)類型編碼原始函數(shù)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 的粉碎規(guī)則不同比如 void func(int) → ?funcYAXHZ但核心邏輯一致編碼函數(shù)名 參數(shù) 作用域。當你在 C 代碼中調(diào)用 C 語言編寫的 SDK如 libIRCNetSDK.so時必須用 extern C 告訴編譯器該函數(shù)按 C 語言規(guī)則編譯禁用名字粉碎。// 1. 無 extern C → 觸發(fā)名字粉碎 void IRC_NET_CALL ExceptionCallback(IRC_NET_HANDLE handle, int type); // GCC 粉碎后_Z20ExceptionCallback18IRC_NET_HANDLEi // SDKC 編寫導出的符號是 ExceptionCallback → 鏈接器找不到報“未定義引用” // 2. 加 extern C → 禁用粉碎按 C 規(guī)則生成符號 extern C void IRC_NET_CALL ExceptionCallback(IRC_NET_HANDLE handle, int type); // 編譯后符號名ExceptionCallback → 和 C 編寫的 SDK 導出符號一致鏈接成功C 調(diào)用 C 庫未加 extern C現(xiàn)象鏈接時報 undefined reference to _Z20ExceptionCallback...原因是 C 粉碎了函數(shù)名而 C 庫導出的是原始名改造 C 庫GCC 編譯用extern C暴露接口禁用名字粉碎// test_lib.cppGCC編譯為libtest.so #ifdef __cplusplus // 僅在C編譯環(huán)境生效 extern C { // 開啟C語言編譯規(guī)則 #endif // 封裝的接口禁用名字粉碎僅暴露原始名func void func(int a, float b) { // 內(nèi)部可寫任意C邏輯類、重載、STL等 // 對外只暴露C風格接口 } #ifdef __cplusplus } // 關閉extern C #endifMSVC 調(diào)用該庫Windows按 C 規(guī)則鏈接// main.cppMSVC編譯 #ifdef __cplusplus extern C { // 告訴MSVC按C規(guī)則查找符號func #endif // 聲明接口和庫中一致 void func(int a, float b); #ifdef __cplusplus } #endif int main() { func(10, 3.14f); // MSVC按原始名func查找匹配GCC庫的導出符號 return 0; }工業(yè)級寫法// 頭文件test_lib.h供調(diào)用方包含 #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跨編譯器 / 平臺的粉碎規(guī)則不兼容比如 GCC 編譯的 C 庫MSVC 調(diào)用時會因粉碎規(guī)則不同導致鏈接失敗解決方案是用 extern C 封裝接口類成員函數(shù)無法禁用粉碎類成員函數(shù)包括虛函數(shù)即使加 extern C 也無效因為要編碼 this 指針、類名因此 SDK 回調(diào)函數(shù)通常設計為全局函數(shù)而非類成員。