好的，我们来系统讲一讲 **动态链接库（DLL/Shared Object）** 的概念、原理、基本设计原则，以及在 C/C++ 中的写法。为了全面，我会从概念到实战一步步展开。

---

## 一、什么是动态链接库（DLL/Shared Object）

1. **定义**

   * **DLL (Dynamic Link Library)**：Windows 系统下的动态链接库，文件后缀 `.dll`
   * **SO (Shared Object)**：Linux/Unix 系统下的动态库，文件后缀 `.so`
   * **本质**：是一段可执行代码（函数、类、资源）打包成的库，可以在程序运行时被加载，而不是编译时静态链接。

2. **与静态库的区别**

   | 特性      | 静态库 (.lib / .a) | 动态库 (.dll / .so) |
   | ------- | --------------- | ---------------- |
   | 链接时间    | 编译时             | 运行时              |
   | 可执行文件大小 | 大（包含库）          | 小（库外部）           |
   | 更新      | 需要重新编译          | 只需替换库文件          |
   | 共享内存    | 不共享             | 可在多个进程共享         |

3. **工作原理**

   * **编译阶段**：编译器使用 `.h` 文件声明函数或类接口，不包含实现。
   * **链接阶段**：在 Windows 上生成 `.lib` 导入库，在 Linux 上生成 `.so` 符号表。
   * **运行阶段**：

     * **显式加载**：程序运行时通过 `LoadLibrary`（Windows）或 `dlopen`（Linux）加载。
     * **隐式加载**：程序启动时自动加载 DLL/so。

---

## 二、基本设计原则

写动态库时，需要考虑以下设计原则：

1. **接口与实现分离**

   * 提供 `.h` 头文件定义函数/类接口
   * 实现放在 `.c/.cpp` 文件中
   * 用户只依赖头文件和库文件

2. **避免全局状态**

   * 动态库可能被多个程序或线程使用
   * 避免使用全局变量，或使用线程安全机制

3. **符号导出/隐藏控制**

   * 只导出需要被外部调用的函数或类
   * Windows：`__declspec(dllexport)` / `__declspec(dllimport)`
   * Linux：`__attribute__((visibility("default")))`

4. **版本管理**

   * 避免破坏兼容性
   * 增加新功能时尽量不要修改已有接口

5. **异常处理**

   * C++ 动态库不要抛跨 DLL 的异常
   * C 接口更安全（extern "C"）

---

## 三、C/C++ 动态库写法

### 1. Windows DLL 示例（C）

**my_lib.h**

```c
#ifndef MY_LIB_H
#define MY_LIB_H

#ifdef MY_LIB_BUILD_DLL
#define MY_API __declspec(dllexport)
#else
#define MY_API __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C" {
#endif

MY_API int add(int a, int b);
MY_API void hello();

#ifdef __cplusplus
}
#endif

#endif
```

**my_lib.c**

```c
#include "my_lib.h"
#include <stdio.h>

int add(int a, int b) {
    return a + b;
}

void hello() {
    printf("Hello from DLL!\n");
}
```

**编译命令（GCC/MinGW）**

```bash
gcc -DMY_LIB_BUILD_DLL -shared my_lib.c -o my_lib.dll -Wl,--out-implib,libmy_lib.a
```

**使用 DLL 的 main.c**

```c
#include "my_lib.h"
#include <stdio.h>

int main() {
    printf("%d\n", add(2, 3));
    hello();
    return 0;
}
```

---

### 2. Linux SO 示例（C）

**my_lib.c** 与 Windows 基本相同，只是编译方式不同：

```bash
gcc -fPIC -shared my_lib.c -o libmy_lib.so
```

**使用 SO**

```c
#include "my_lib.h"
#include <stdio.h>
#include <dlfcn.h>

int main() {
    void* handle = dlopen("./libmy_lib.so", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "Cannot open library: %s\n", dlerror());
        return 1;
    }

    // 加载函数
    int (*add)(int, int) = dlsym(handle, "add");
    void (*hello)() = dlsym(handle, "hello");

    printf("%d\n", add(2, 3));
    hello();

    dlclose(handle);
    return 0;
}
```

---

### 3. C++ 类 DLL

**my_class.h**

```cpp
#ifndef MY_CLASS_H
#define MY_CLASS_H

#ifdef MY_LIB_BUILD_DLL
#define MY_API __declspec(dllexport)
#else
#define MY_API __declspec(dllimport)
#endif

class MY_API MyClass {
public:
    MyClass();
    void greet();
};

#endif
```

**my_class.cpp**

```cpp
#include "my_class.h"
#include <iostream>

MyClass::MyClass() {}
void MyClass::greet() {
    std::cout << "Hello from C++ DLL" << std::endl;
}
```

**注意**：C++ DLL 导出类要小心跨模块内存分配和异常。

---

## 四、常用技巧与注意事项

1. **显式 vs 隐式链接**

   * **显式**：运行时加载 `LoadLibrary/dlopen`，灵活，便于插件化
   * **隐式**：编译时依赖 `.lib` 或 `.so`，启动自动加载

2. **导出 C 接口，兼容 C++**

   ```cpp
   extern "C" MY_API int add(int a, int b);
   ```

   * 避免 C++ 名字修饰（Name Mangling）导致外部无法调用

3. **线程安全**

   * 避免 DLL 内部静态或全局对象在多线程环境下出错
   * 可以使用局部静态或线程局部存储

4. **资源管理**

   * DLL 占用系统资源，注意释放句柄 `dlclose` / `FreeLibrary`

---

✅ 总结：

* **DLL/SO** 是运行时可加载的库，接口/实现分离，可减少可执行文件体积并支持更新。
* **设计原则**：接口分离、导出控制、避免全局状态、版本管理、异常处理。
* **写法**：

  * Windows：`__declspec(dllexport/dllimport)` + `.dll` + 可选 `.lib` 导入库
  * Linux：`-fPIC -shared` + `.so` + `dlopen/dlsym/dlclose`
* **C++**：要注意名字修饰、异常、内存分配问题，必要时导出 C 接口。

---

如果你愿意，我可以给你画一个 **DLL/so 使用流程图 + C/C++ 示例结构图**，直观展示头文件、实现文件、库文件、调用端之间的关系，非常适合新手理解。

你希望我画吗？
没错！你理解得很对，`.h` 文件在这里就是 **接口文件**（Interface）：

* 它 **声明**了函数、类或者变量，但不包含真正的实现。
* 用户只需要包含这个 `.h` 文件就能调用库里的功能，而不需要关心实现细节。
* `.c/.cpp` 文件才是真正的 **实现文件**（Implementation），负责具体逻辑。

可以把它类比成 **“功能说明书”**：告诉你这个库能干什么、怎么调用，但具体怎么干是在背后隐藏的。

如果你愿意，我可以顺便给你画个小图，把 `.h`、`.c/.cpp`、DLL/so、调用端之间的关系可视化，一眼就懂。你想要吗？


完全正确 ✅

你理解得没错：**头文件只“告诉编译器函数长啥样”，不负责引入其它库的依赖**。

详细拆一下：

---

## 1️⃣ 你的 `my_str.h` 现在

```c
MY_STR_API double evaluate(const char* exp);
```

* 只声明了 `evaluate()`
* 没有 `#include <stdio.h>`
* 也没有 `#include <stdlib.h>` 等

> 也就是说，**头文件本身没有引入 printf、malloc 等依赖**

---

## 2️⃣ main.c 如果要用 printf

```c
#include "my_str.h"

int main() {
    printf("%f\n", evaluate("1+2*3"));
    return 0;
}
```

* 编译器此时看到 `printf` 的时候 **不知道它的类型**
* 会报错或者警告：`implicit declaration of printf`

所以你必须：

```c
#include <stdio.h>
#include "my_str.h"
```

---

## 3️⃣ 原因

* `my_str.h` **只负责提供 DLL 接口**
* 不负责用户程序可能会用的其它东西
* 这是 **模块化的设计原则**
* 否则你头文件里每一个函数都要 `#include <stdio.h>`，用户不想用 printf 也被迫引入，非常不优雅

---

## 4️⃣ 小结经验法则

1. **头文件只放自己模块的接口和必要类型定义**
2. **用户程序用什么库函数，就自己 include**
3. **DLL 内部用什么库函数，放在 DLL cpp/c 文件里 include**

> 换句话说，**头文件不会也不应该“偷带”用户的依赖”**
> 这和 C++ 的 class 设计很像：class 内部用什么 STL，外部不用关心

---

你如果愿意，我可以画一张 **DLL / 头文件 / 用户 main.c 的依赖关系图**，让你一眼就明白谁负责什么。

你想让我画吗？