C++如何实现跨平台的动态链接库加载封装类-C++-PHP中文网

根本区别在于：windows用loadlibrary/getprocaddress/freelibrary，linux用dlopen/dlsym/dlclose；二者函数签名、错误处理（getlasterror() vs dlerror）、符号可见性（默认导出vs默认隐藏）、路径解析及依赖搜索策略均不同，必须通过平台分支抽象隔离。

c++如何实现跨平台的动态链接库加载封装类

Windows 和 Linux 下的动态库加载 API 差异在哪

根本区别在于：Windows 用 LoadLibrary/GetProcAddress/FreeLibrary，Linux 用 dlopen/dlsym/dlclose。二者函数签名、错误处理方式、符号可见性默认行为都不同，直接封装必须做抽象隔离。

LoadLibrary 返回 HMODULE（本质是 void*），dlopen 返回 void*，类型可统一为 void*，但语义不能混用
Windows 默认导出所有符号需加 __declspec(dllexport)，Linux 默认隐藏符号，需编译时加 -fvisibility=default 或显式用 __attribute__((visibility("default")))
错误获取：Windows 用 GetLastError()，Linux 用 dlerror()，不能共用同一错误字符串缓存

如何设计一个最小可行的跨平台封装类接口

核心是隐藏平台差异，暴露一致的加载/查找/卸载逻辑。不追求泛型模板或 RAII 自动管理（易引入生命周期歧义），先保证功能正交、错误可追溯。

构造函数只接受路径（const std::string&），不自动加载；提供 load() 显式调用，返回 bool 并记录错误码
get_symbol(const char* name) 返回 void*，不做强制类型转换——类型安全由调用方用 reinterpret_cast 保证，避免模板膨胀和 ABI 风险
内部用 #ifdef _WIN32 分支管理两套实现，避免宏污染头文件；头文件里只声明统一接口

示例关键成员：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

class DynamicLibrary {
    void* handle_ = nullptr;
#ifdef _WIN32
    std::string last_error_;
#endif
public:
    bool load(const std::string& path);
    void* get_symbol(const char* name);
    void unload();
};

Linux 下 `dlopen` 的常见陷阱有哪些

最常踩的坑不是语法，而是链接模型和运行时路径问题。

未加 -ldl 链接选项 → 链接时报错 undefined reference to `dlopen`
路径传入相对路径（如 "./plugin.so"）但当前工作目录非预期 → 加载失败；建议用绝对路径或 RTLD_GLOBAL + LD_LIBRARY_PATH 配合
符号未导出：C++ 编译器对函数名做 mangling，C 接口必须用 extern "C" 声明，否则 dlsym 查不到
dlopen 默认使用 RTLD_LOCAL，若插件内部又依赖其他 so，且那些 so 未被主程序或其它已加载 so 导出符号，则会失败；必要时用 RTLD_GLOBAL

Windows 下 `LoadLibrary` 的路径与依赖问题怎么解

比 Linux 更隐蔽：它不遵循 POSIX 路径规则，且 DLL 依赖解析顺序复杂。

路径含中文或空格时，LoadLibraryA 可能失败，必须用 LoadLibraryW + std::wstring（尤其在 VS2015+ 默认启用 Unicode）
DLL 依赖的其它 DLL 不在 PATH、当前目录、系统目录时，LoadLibrary 直接失败，无详细原因；可用 Dependency Walker 或 dumpbin /dependents 查依赖树
重复 LoadLibrary 同一路径会返回相同句柄，但计数器递增；必须配对调用 FreeLibrary 相同次数，否则资源泄漏
调试时若看到错误码 ERROR_MOD_NOT_FOUND，大概率是依赖 DLL 缺失，而非目标 DLL 本身找不到