C++中创建和使用动态库需定义接口、实现功能、编译为.dll或.so文件，并在主程序中隐式链接或显式加载；通过extern “C”避免名称修饰，用CMake实现跨平台构建，规避ABI不兼容与内存管理问题。
C++中创建和使用动态库，简单来说，就是把一部分代码编译成一个独立的文件（在Windows上是
.dll
，Linux上是
.so
），这个文件在程序运行时才会被加载。这样做的好处显而易见：模块化、代码复用、减少主程序体积，甚至还能实现热更新。它就像是给你的程序配备了一套可插拔的工具箱，用的时候再拿出来，不用的时候就放在一边，不占地方。
解决方案
要创建和使用C++动态库，我们通常会经历几个步骤：定义接口、实现功能、编译库文件，最后在主程序中链接或加载。这中间有很多细节，我通常会这么操作：
1. 定义库的接口（头文件）
这是库的“门面”，告诉使用者库里有哪些功能。我会创建一个头文件，比如
mylibrary.h
。
立即学习“C++免费学习笔记（深入）”；
// mylibrary.h#pragma once // 确保头文件只被包含一次#ifdef _WIN32 #ifdef MYLIBRARY_EXPORTS #define MYLIBRARY_API __declspec(dllexport) // 导出符号 #else #define MYLIBRARY_API __declspec(dllimport) // 导入符号 #endif#else // Linux/macOS #define MYLIBRARY_API __attribute__((visibility("default"))) // 导出符号#endif// 这是一个简单的加法函数extern "C" MYLIBRARY_API int add(int a, int b);// 这是一个C++类示例，如果需要导出类，可能会复杂一些class MYLIBRARY_API MyClass {public: MyClass(); void greet(); // 注意：导出C++类时，其所有公共成员函数和数据成员都需要被导出， // 并且要考虑ABI兼容性，这有时是个大坑。};
这里
extern "C"
是一个关键点，它告诉编译器使用C语言的函数命名和调用约定，这能极大地提高跨语言和跨编译器之间的兼容性，避免C++特有的名称修饰（name mangling）带来的麻烦。对于C++类，情况会复杂很多，因为C++的ABI（应用程序二进制接口）在不同编译器和版本间差异很大，所以很多时候，为了稳定性和兼容性，动态库会选择导出C风格的接口来封装C++对象。
2. 实现库的功能（源文件）
接着，我会编写
mylibrary.cpp
来实现
mylibrary.h
中声明的函数和类。
// mylibrary.cpp#define MYLIBRARY_EXPORTS // 在编译库时定义，表示要导出符号#include "mylibrary.h"#include int add(int a, int b) { return a + b;}MyClass::MyClass() { std::cout << "MyClass constructor called." << std::endl;}void MyClass::greet() { std::cout << "Hello from MyClass in dynamic library!" << std::endl;}
3. 编译动态库
这步是核心，将源文件编译成
.dll
或
.so
文件。
Linux (使用g++)
g++ -shared -fPIC -o libmylibrary.so mylibrary.cpp# -shared 告诉g++生成一个共享库# -fPIC (Position Independent Code) 是生成位置无关代码，这是共享库的必要条件# -o libmylibrary.so 指定输出文件名为libmylibrary.so
生成
libmylibrary.so
。
Windows (使用g++，如果你用MinGW)
g++ -shared -o mylibrary.dll mylibrary.cpp -Wl,--out-implib,libmylibrary.a# -shared 告诉g++生成一个共享库# -o mylibrary.dll 指定输出文件名为mylibrary.dll# -Wl,--out-implib,libmylibrary.a 告诉链接器同时生成一个导入库（.lib或.a），# 应用程序链接时需要用到这个导入库。
生成
mylibrary.dll
和
libmylibrary.a
。
Windows (使用MSVC)通常在Visual Studio中创建一个DLL项目，它会自动处理这些细节。命令行的话，大致是：
cl /LD mylibrary.cpp# /LD 选项用于生成DLL
这会生成
mylibrary.dll
和
mylibrary.lib
。
4. 使用动态库
使用动态库有两种主要方式：隐式链接（compile-time linking）和显式加载（runtime loading）。
隐式链接（推荐用于已知依赖）这是最常见的方式，你的程序在编译时就知道它需要这个库。
// main.cpp#include "mylibrary.h" // 包含库的头文件#include int main() { std::cout << "Using add function from dynamic library: " << add(5, 3) << std::endl; MyClass obj; obj.greet(); return 0;}
Linux 编译和运行
g++ main.cpp -L. -lmylibrary -o myapp# -L. 告诉链接器在当前目录查找库文件# -lmylibrary 告诉链接器链接libmylibrary.so# -o myapp 指定输出可执行文件名为myapp# 运行前，需要让系统找到libmylibrary.so。# 最简单的方法是将其复制到系统库路径（如/usr/local/lib），# 或者设置LD_LIBRARY_PATH环境变量：export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH./myapp
Windows 编译和运行 (使用g++)
g++ main.cpp -L. -lmylibrary -o myapp.exe# -L. 告诉链接器在当前目录查找导入库libmylibrary.a# -lmylibrary 告诉链接器链接libmylibrary.a# 运行前，mylibrary.dll必须在myapp.exe同目录或系统PATH环境变量中。# 将mylibrary.dll复制到myapp.exe所在目录。./myapp.exe
显式加载（推荐用于插件系统或按需加载）这种方式更灵活，程序在运行时才决定是否加载某个库，甚至可以在运行时切换不同的库版本。这通常涉及平台特定的API。
// main_dynamic_load.cpp#include #ifdef _WIN32 #include #else #include // 用于Linux/macOS#endif// 定义函数指针类型，匹配库中函数的签名typedef int (*AddFunc)(int, int);typedef void (*GreetFunc)(void*); // 如果MyClass::greet是非静态成员函数，需要传入this指针int main() { #ifdef _WIN32 HMODULE hLib = LoadLibrary("mylibrary.dll"); if (!hLib) { std::cerr << "Failed to load mylibrary.dll" << std::endl; return 1; } AddFunc add = (AddFunc)GetProcAddress(hLib, "add"); // 对于C++类，直接通过GetProcAddress获取成员函数指针非常复杂且不推荐， // 通常会导出C风格的工厂函数来创建和销毁对象，以及C风格的包装函数来调用对象方法。 // 这里为了简化示例，我们假设MyClass::greet是一个C风格接口包装的函数 // 或者我们只导出C风格函数。 // 如果要调用MyClass的greet，我们可能需要一个C风格的包装函数： // extern "C" MYLIBRARY_API void MyClass_create(MyClass** obj); // extern "C" MYLIBRARY_API void MyClass_greet(MyClass* obj); // extern "C" MYLIBRARY_API void MyClass_destroy(MyClass* obj); // 然后通过GetProcAddress获取这些C风格函数。 // 鉴于示例的MyClass，这里就只演示add函数。 if (add) { std::cout << "Dynamically loaded add function: " << add(10, 20) << std::endl; } else { std::cerr << "Failed to find 'add' function." << std::endl; } FreeLibrary(hLib); #else // Linux/macOS void* handle = dlopen("./libmylibrary.so", RTLD_LAZY); // RTLD_NOW 立即解析所有符号，RTLD_LAZY 延迟解析 if (!handle) { std::cerr << "Failed to load libmylibrary.so: " << dlerror() << std::endl; return 1; } AddFunc add = (AddFunc)dlsym(handle, "add"); if (add) { std::cout << "Dynamically loaded add function: " << add(10, 20) << std::endl; } else { std::cerr << "Failed to find 'add' function: " << dlerror() << std::endl; } dlclose(handle); #endif return 0;}
编译和运行 (无链接库)
# Linuxg++ main_dynamic_load.cpp -ldl -o myapp_dynamicexport LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH./myapp_dynamic# Windows (g++)g++ main_dynamic_load.cpp -o myapp_dynamic.exe# 确保mylibrary.dll在同目录或PATH中./myapp_dynamic.exe
显式加载的灵活性是其最大的优势，但编程复杂度也更高，需要手动管理库的加载和卸载，以及函数指针的类型转换。
动态库和静态库有什么区别？为什么我们需要动态库？
说实话，这两种库的本质都是为了代码复用，但实现方式和带来的影响大相径庭。
静态库（
.lib
或
.a
）在编译时就会被完整地嵌入到你的可执行文件中。你可以想象成，你的程序在建造的时候，就把所有需要的砖块、水泥都一股脑儿地堆进了自己的地基里。好处是，程序一旦编译完成，它就是个“独立王国”，不需要依赖外部的库文件就能运行，部署起来非常省心，只要把可执行文件拷过去就行。但缺点也很明显：如果多个程序都用了同一个静态库，那么每个程序都会包含一份这个库的代码，导致可执行文件体积膨胀，而且一旦库有了更新，所有依赖它的程序都必须重新编译、重新发布。这就像是每个房子都自己烧砖，效率低，还浪费资源。
动态库（
.dll
或
.so
）则不同，它在编译时只是记录了一个“我需要这个库”的标记，实际的代码并不会被嵌入。只有在程序运行时，操作系统才会去加载这个动态库。这就像是你的房子只记录了“我需要去建材市场买砖”，等到真正要盖的时候才去拿。这样做的好处是多方面的：
减小程序体积：你的可执行文件只包含自己的核心逻辑，动态库的代码是分离的。模块化和复用：多个程序可以共享同一个动态库文件。操作系统通常只会将动态库加载到内存一次，然后映射给所有需要它的进程，这大大节省了内存。易于更新和维护：如果动态库有了bug修复或功能更新，你只需要替换掉动态库文件本身，而不需要重新编译和发布所有依赖它的程序。这对于大型项目或者插件系统来说，简直是福音。按需加载：通过显式加载的方式，程序可以在运行时根据需要加载特定的库，甚至可以实现插件式的架构，非常灵活。
当然，动态库也不是没有缺点。最头疼的可能就是“DLL Hell”（Windows上）或“依赖地狱”（Linux上）的问题了。不同版本的动态库可能导致符号冲突，或者系统找不到正确的库文件，这在部署和维护时需要特别注意。但总的来说，在现代软件开发中，动态库的优势往往盖过其带来的部署复杂性，尤其是在需要构建大型、模块化、易于维护的系统时。
动态库在实际项目中可能遇到哪些坑？如何规避？
动态库虽然好用，但实际用起来，踩坑是家常便饭。我总结了一些常见的“坑”和我的规避策略：
1. 找不到库文件（“No such file or directory”）
这是最基础也最常见的错误。程序运行时找不到
.dll
或
.so
文件。
Linux：通常是
LD_LIBRARY_PATH
环境变量没设置对，或者库文件不在
/usr/lib
、
/usr/local/lib
等标准路径。我常用的方法是，如果库是项目内部的，就通过
LD_LIBRARY_PATH
指定；如果是系统级的，就安装到标准路径，或者在
ld.so.conf
中添加路径并运行
ldconfig
。Windows：
PATH
环境变量没包含库文件路径，或者库文件没放在可执行文件同目录下。最省事儿的办法就是把
dll
文件放在
exe
同目录，或者把它加入到系统
PATH
。
2. 符号找不到（“undefined symbol”）
链接器或者运行时加载器找不到库中某个函数的定义。
原因：函数没有正确导出（比如Windows上忘了
__declspec(dllexport)
，或者Linux上忘了
__attribute__((visibility("default")))
）。C++函数名称修饰（name mangling）问题。如果库和主程序用不同编译器编译，或者
extern "C"
没用对，就容易出现。函数签名不匹配。规避：仔细检查导出宏是否正确使用。对于C++函数，尽量使用
extern "C"
导出C风格的接口，或者确保库和主程序使用相同的编译器和编译选项。使用
nm
（Linux）或
dumpbin /exports
（Windows）检查库文件实际导出了哪些符号，以及它们的名称。
3. ABI（Application Binary Interface）不兼容
这是C++动态库开发中最让人头疼的问题之一。C++的ABI在不同编译器、甚至同一编译器的不同版本之间都可能不兼容。这意味着，用GCC编译的C++库，可能无法被MSVC编译的C++程序直接使用，即使它们都遵循C++标准。
原因：类布局、虚函数表、名称修饰、异常处理机制等都可能不同。规避：最稳妥的方案是使用C风格接口：动态库只导出
extern "C"
的函数，这些函数内部可以调用C++代码，但对外接口是纯C的。这样可以避免C++ ABI不兼容的问题。保持编译器一致：如果实在要导出C++类或模板，尽量确保库和所有依赖它的应用程序都使用同一个编译器、同一个版本，并且使用相同的编译选项（比如调试/发布模式、运行时库类型等）。PIMPL（Pointer to Implementation）模式：将C++类的私有实现细节隐藏在一个指针后面，只在头文件中暴露一个简单的接口，这样可以减少ABI变化的冲击。
4. 内存管理跨库边界问题
在动态库中
new
出来的内存，如果尝试在主程序中
delete
，或者反过来，可能会导致崩溃或内存泄漏。因为
new
和
delete
可能由不同的运行时库实现，它们内部的内存分配器可能不兼容。
规避：“谁分配谁释放”原则：在哪个模块分配的内存，就在哪个模块释放。提供工厂和销毁函数：如果库需要创建对象并返回给主程序，库应该提供一个函数来创建对象（如
createMyObject()
）和一个函数来销毁对象（如
destroyMyObject()
），主程序只调用这些库提供的接口。智能指针：使用
std::shared_ptr
或
std::unique_ptr
，但要注意，如果自定义删除器，仍然需要遵循“谁分配谁释放”的原则，或者确保删除器在库内部执行。
5. 版本冲突（DLL Hell）
当系统中有多个程序依赖同一个动态库，但它们需要不同版本时，就会出现问题。
规避：命名版本化：例如
libmylibrary.so.1.0
，并通过软链接
libmylibrary.so
指向最新版本。私有部署：将动态库和应用程序放在同一个目录下，不依赖系统路径。这样每个应用程序都有自己的库副本，但会增加磁盘空间占用。使用
rpath
或
runpath
（Linux）：在编译可执行文件时，指定一个相对路径来查找动态库，例如
g++ main.cpp -L. -lmylibrary -Wl,-rpath=. -o myapp
。这让程序在运行时优先在指定路径查找库。
处理这些问题，没有银弹，通常需要结合具体场景，权衡灵活性和稳定性。但核心思想是：尽可能地隔离和标准化接口。
如何实现跨平台兼容的动态库开发？
跨平台开发动态库，这本身就是一个挑战，但并非不可逾越。我的经验是，关键在于“抽象”和“约定”，以及对底层差异的清晰认知。
1. 统一构建系统：CMake是你的好朋友
手动为Windows、Linux、macOS编写不同的Makefile或项目文件，那简直是噩梦。CMake就是为解决这个问题而生的。它提供了一种高级、平台无关的语言来描述你的项目结构和编译规则，然后CMake会根据目标平台生成相应的构建文件（如Makefile、Visual Studio项目文件）。
一个简单的CMakeLists.txt示例：
# CMakeLists.txtcmake_minimum_required(VERSION 3.10)project(MyLibrary CXX)# 定义导出宏# 这是一个更通用的方式来处理dllexport/dllimport和visibilityconfigure_file( mylibrary_export.h.in mylibrary_export.h @ONLY)add_library(mylibrary SHARED mylibrary.cpp)target_include_directories(mylibrary PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})# 链接器设置，例如在Linux上添加rpathif(UNIX) target_link_options(mylibrary PUBLIC "-Wl,-rpath,$ORIGIN")endif()# 安装目标（可选）install(TARGETS mylibrary DESTINATION lib)install(FILES mylibrary.h DESTINATION include)install(FILES ${CMAKE_BINARY_DIR}/mylibrary_export.h DESTINATION include)
配合
mylibrary_export.h.in
：
// mylibrary_export.h.in#pragma once#ifdef _WIN32 #ifdef mylibrary_EXPORTS // CMake会自动为SHARED库定义这个宏 #define MYLIBRARY_API __declspec(dllexport) #else #define MYLIBRARY_API __declspec(dllimport) #endif#else // Linux/macOS #
以上就是c++++如何创建和使用动态库_c++动态链接库.so/.dll制作与使用的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1476245.html
微信扫一扫 
支付宝扫一扫 
