一、库的内部实现：隐藏符号的艺术

各位同学，今天我们来聊聊库的内部实现。说实话，这块内容我当年自学的时候踩过不少坑。你想想看，辛辛苦苦写了一个库，结果用户能调用你所有的内部函数——这多尴尬？

我刚开始做C++库时，就犯过这种错误。一个工具函数被外部调用了，后来我想重构，结果一堆代码依赖它，改都不敢改。嗯，今天我们就来解决这个问题。

1.1 隐藏内部符号：为什么需要？

先问个问题：你写的库，哪些东西应该暴露给用户？

答案很简单：只暴露接口，隐藏实现。这不仅是封装原则，更是工程实践。

隐藏内部符号的好处：

• 减少符号冲突——你的内部函数不会和用户代码打架
• 控制ABI——内部实现随便改，不影响外部调用
• 减小库体积——不导出的符号，链接器可以优化掉
• 提升加载速度——动态库符号表小了，解析更快

1.2 __attribute__((visibility))：控制符号可见性

GCC和Clang提供了__attribute__((visibility))，这是控制符号导出的利器。

用法很简单：

// 默认隐藏
__attribute__((visibility("hidden"))) void internal_helper() {
    // 内部实现
}

// 显式导出
__attribute__((visibility("default"))) void public_api() {
    // 对外接口
}

我个人习惯在编译时加-fvisibility=hidden，这样所有符号默认隐藏，只有标记了default的才导出。

举个例子：

// 编译命令
g++ -fvisibility=hidden -shared -o libmylib.so mylib.cpp

// mylib.cpp
void internal_func() { }  // 默认隐藏，不导出

__attribute__((visibility("default"))) 
void public_func() { }    // 显式导出

我在项目中遇到过一个问题：有个第三方库导出了几千个符号，导致链接时间暴涨。后来发现他们没加-fvisibility=hidden。加上之后，符号表从3000个降到了50个，链接时间从30秒降到了2秒。

1.3 Pimpl惯用法：编译防火墙

Pimpl（Pointer to Implementation）是C++特有的隐藏实现技巧。说白了，就是把私有成员藏到指针后面。

看代码：

// widget.h
class Widget {
public:
    Widget();
    ~Widget();
    void doSomething();
    
private:
    struct Impl;  // 前向声明
    Impl* pImpl;  // 指向实现的指针
};

// widget.cpp
struct Widget::Impl {
    int data;
    std::string name;
    void helper() { /* 内部逻辑 */ }
};

Widget::Widget() : pImpl(new Impl) {}
Widget::~Widget() { delete pImpl; }
void Widget::doSomething() { pImpl->helper(); }

这样做的好处：

• 编译隔离——修改Impl内部，用户代码不用重新编译
• 隐藏实现——头文件里只有接口声明
• ABI稳定——Impl可以随便改，类的大小不变

我曾经维护过一个大型SDK，头文件里塞满了私有成员。每次加个字段，所有用户都得重新编译。改用Pimpl后，编译时间从40分钟降到了5分钟。嗯，这感觉真好。

1.4 内联函数处理：导出还是不导出？

内联函数在库里的处理比较特殊。你想想看，内联函数是在调用处展开的，那它到底该不该导出？

答案是：看情况。

场景	处理方式	原因
内联函数在头文件中定义	不导出，直接展开	每个编译单元都有自己的副本
内联函数在.cpp中定义	必须导出，否则外部无法调用	编译器无法跨编译单元内联
模板函数	通常不导出，实例化时展开	模板是编译时多态

我建议的做法：

// 头文件中定义内联函数
inline int add(int a, int b) {
    return a + b;
}

// 或者用static inline
static inline int multiply(int a, int b) {
    return a * b;
}

// 如果一定要导出内联函数
__attribute__((visibility("default"))) 
inline int exported_inline(int x) {
    return x * 2;
}

这里有个坑：内联函数如果被导出，它的实现必须始终可见。否则用户代码链接时会报错。

我曾经遇到过一个bug：库升级后，某个内联函数的实现变了，但用户代码没重新编译。结果运行时行为不一致，排查了两天才找到原因。从那以后，我尽量不在导出的接口里用内联函数。

1.5 知识体系总览

下面这张图总结了本章的核心内容：

1.6 实战建议

总结一下我的经验：

1. 编译时加-fvisibility=hidden，这是最省事的做法
2. 用宏封装可见性属性，方便跨平台

#if defined(_MSC_VER)
    #define EXPORT __declspec(dllexport)
    #define HIDDEN
#elif defined(__GNUC__) || defined(__clang__)
    #define EXPORT __attribute__((visibility("default")))
    #define HIDDEN __attribute__((visibility("hidden")))
#endif

EXPORT void public_api();
HIDDEN void internal_helper();

3. 头文件只放接口声明，实现细节藏到cpp里
4. 内联函数尽量放在头文件，不要导出
5. 定期检查符号表，确保没有意外导出

好了，这一章的内容就到这里。记住一句话：库的设计，就是接口的设计；接口的设计，就是符号的管理。把符号控制好了，你的库就成功了一半。

---