📚 课程目录第4章 C++语言绑定

第4章：C++语言绑定——类、多态与异常的那些坑

大家可能觉得，给C++库做语言绑定，不就拿FFI把函数导出就行了？嗯，真这么想就太天真了。C++的复杂性，主要就体现在它的面向对象特性上。类怎么构造、怎么销毁？虚函数表能不能跨语言使用？异常能不能从C API里扔出来？

这一章，我就把这几个核心问题拆开来讲。每个问题背后，都有我在项目中踩过的坑。

4.1 类与对象绑定：从C++对象到C API的桥接

C++类本身没有标准的ABI。不同编译器，甚至同一编译器的不同版本，对this指针的传递方式都可能不同。所以，你不能直接把一个C++类暴露给其他语言。

那么怎么绑？ 我习惯的做法是：用C API包装类的构造函数、析构函数和成员函数。这个过程叫做“手柄模式”（Handle Pattern）或“不透明指针”（Opaque Pointer）。

看一个简单的例子。假设我们在加密SDK里有一个XxxCipher类：

// C++ 侧
class XxxCipher {
public:
    XxxCipher(const std::string& key);
    ~XxxCipher();
    std::vector<uint8_t> encrypt(const std::vector<uint8_t>& plaintext);
private:
    // ... 内部数据
};

// C 绑定层
extern "C" {
    void* cipher_create(const char* key, size_t key_len);
    void cipher_destroy(void* handle);
    int cipher_encrypt(void* handle, 
                       const uint8_t* plaintext, size_t pt_len,
                       uint8_t* out, size_t* out_len);
}

这里的关键是void*。它在C层代表一个不透明的对象指针，在C++层则通过reinterpret_cast转回真正的类指针。这个过程看起来简单，但有个容易忽略的问题：

对象生命周期管理
我曾经在一个项目里，因为忘了在析构函数里释放内部资源，导致内存泄漏。对象必须在语言绑定层正确销毁，否则就会造成资源泄露。

我建议所有构造函数返回的不透明指针，都必须有对应的析构函数。并且，析构函数要保证线程安全——因为其他语言可能在任何线程调用它。你想想看，如果用户在一个线程里构造，在另一个线程里析构，而内部没有做同步，那就麻烦了。

4.2 多态与继承：虚函数表能跨语言共享吗？

C++的多态核心是虚函数表（vtable）。每个包含虚函数的类都有一个vtable指针，指向一个函数指针数组。这个机制在C++内部很可靠，但在跨语言绑定时，问题就来了。

为什么？ 因为其他语言不能直接访问C++的vtable。比如，你在C++里定义了一个抽象基类EVP_PKEY，子类RSA_PKEY实现了它的虚函数。如果在C语言里传递一个EVP_PKEY*指针，并尝试调用它的虚函数，C侧根本就没有vtable的概念。

怎么解决？ 我遇到过几种方案：

方案	做法	优点	缺点
Wide-Object 模式	不暴露虚函数表，而是为每个具体类创建独立的C API函数表	简单、稳定，不依赖vtable	不支持在绑定层扩展多态行为
Virtual C API	在C层实现一个虚函数表结构体，让C++类填充它	可以在C侧模拟多态	维护成本高，每个虚函数都要手动注册
Callback Bridge	把虚函数调用转成C回调函数	灵活，支持在语言绑定层重写	性能开销较大

我个人更推荐第一种。说白了，在语言绑定时追求完美的多态继承，往往得不偿失。你想想看，调用方用的是Python、Java或Rust，它本身就有自己的多态机制，根本用不着C++的vtable。

我的经验
在做一个PKCS#11的C++绑定层时，我一开始想保留完整的继承层次。结果生成的C接口极其复杂，用户根本不知道怎么用。后来我干脆把所有具体类都扁平化，每个类对应一组独立的C函数。效果反而更好。

4.3 异常处理：C API 里不能扔异常！

C++的异常处理机制是语言级别的。如果一个C++函数抛出异常，而调用者恰好是C语言，那整个程序就会崩溃。原因很简单：C栈帧不支持栈展开。

这是一个灾难场景。我在早期做绑定时，就因为这个原因导致一个银行前置机进程直接core dump。从那以后，我严格规定：所有C API边界上，不能有C++异常逃逸。

怎么办？ 标准做法是在C++侧捕获异常，并把它翻译成错误码或错误状态。比如：

// C++ 侧
int cipher_encrypt_wrapper(void* handle, 
                           const uint8_t* in, size_t in_len,
                           uint8_t* out, size_t* out_len) {
    try {
        auto cipher = static_cast<XxxCipher*>(handle);
        auto result = cipher->encrypt({in, in + in_len});
        if (*out_len < result.size()) {
            return CAPI_ERR_BUFFER_TOO_SMALL;
        }
        memcpy(out, result.data(), result.size());
        *out_len = result.size();
        return CAPI_OK;
    } catch (const CryptoException& e) {
        // 把异常信息记录下来，让用户通过另一个API获取
        set_last_error(e.what());
        return CAPI_ERR_CRYPTO;
    } catch (const std::bad_alloc&) {
        return CAPI_ERR_OUT_OF_MEMORY;
    } catch (...) {
        return CAPI_ERR_UNKNOWN;
    }
}

你可能注意到了，异常信息被存到了一个线程局部变量里，通过cipher_get_last_error()这样的API查询。这个模式很常见，因为它不会破坏C函数的简单接口。

关键点

异常处理在绑定层的挑战，并不仅仅是“不能抛出异常”。更重要的是：

- 异常类型的不同语言映射（比如C++的std::logic_error在Python里应该变成什么？）

- 异常栈信息的丢失

- 跨模块的异常（如果你用动态库，不同编译器编译的库之间的异常不兼容）

我记得有个项目，用户用MSVC编译了自己的调用方，但绑定的动态库是用MinGW编译的。结果在C++侧捕获异常时，因为RTTI不匹配，catch直接失效。最后我们只能把所有C++异常在绑定层转成C错误码，彻底避免跨编译器的异常传播。

好了，到这里我们理清了C++绑定中几个最核心的问题。对象要用手柄模式，多态要扁平化处理，异常要在边界转成错误码。说实话，这些经验都是我用一次次的线上故障换来的。如果你正在做C++的绑定层，千万别在这三个地方偷懒。