30. C++23展望：std::out_ptr与std::inout_ptr，简化C互操作

说实话，做C++和C混合编程的项目，最让人头疼的就是指针管理。我早年接手过一个遗留系统，里面充斥着各种 void** 和 int* 的传参方式。每次看到那种「传入指针，函数内部帮你分配内存」的C风格API，我都得深吸一口气——因为这意味着后面得小心翼翼地配对释放，稍不留神就内存泄漏了。

C++23 引入的 std::out_ptr 和 std::inout_ptr，说白了就是专门解决这个痛点的。它们让你能用智能指针去对接那些「不守规矩」的C函数，把脏活累活交给标准库去干。

30.1 问题背景：C互操作中的指针困境

我们先看一个典型的C API长什么样。很多C库的函数会这样设计：

// C 风格的初始化函数
int create_buffer(void** out_ptr, size_t size);
void free_buffer(void* ptr);

调用方得先声明一个 void* 变量，传它的地址进去，函数内部帮你分配内存。然后你用完还得记得调用 free_buffer。用C++写起来大概是这样：

void* raw_ptr = nullptr;
if (create_buffer(&raw_ptr, 1024) != 0) {
    // 处理错误
}
// ... 使用 raw_ptr ...
free_buffer(raw_ptr);

嗯，这里要注意：如果中间抛出异常，free_buffer 可能就跳过了。这就是赤裸裸的泄漏风险。我以前在一个图像处理库中遇到过类似情况，一个异常导致缓冲区没释放，程序跑了三天后内存爆了——排查起来特别痛苦。

30.2 传统方案的局限性

你可能会说：「用 unique_ptr 加自定义删除器不就行了？」确实可以，但写起来并不优雅：

auto deleter = [](void* p) { free_buffer(p); };
std::unique_ptr<void, decltype(deleter)> ptr(nullptr, deleter);

void* raw = nullptr;
if (create_buffer(&raw, 1024) != 0) {
    throw std::runtime_error("create_buffer failed");
}
ptr.reset(raw);

看到了吗？你得先声明一个空指针，调用C函数，再手动 reset。这中间其实有个空档期——如果 create_buffer 成功了但 reset 之前出了异常，资源就悬空了。说白了，这种写法只是把问题从「手动释放」变成了「手动接管」，并没有从根本上解决资源安全转移的问题。

30.3 std::out_ptr：只输出的指针适配器

std::out_ptr 就是为上面这种场景量身定做的。它接受一个智能指针，返回一个适配器对象，这个适配器能直接当作 void** 传给C函数。函数执行完毕后，智能指针会自动接管资源。

来看代码：

#include <memory>
#include <cstdio>

// 假设这是C库提供的函数
extern "C" int create_buffer(void** out, size_t size);
extern "C" void free_buffer(void* ptr);

int main() {
    auto deleter = [](void* p) { free_buffer(p); };
    std::unique_ptr<void, decltype(deleter)> buf(nullptr, deleter);

    // 关键在这里：用 out_ptr 包装 unique_ptr
    if (create_buffer(std::out_ptr(buf), 1024) != 0) {
        return 1;
    }

    // 此时 buf 已经持有了分配的内存
    // 离开作用域时自动调用 free_buffer
    return 0;
}

我个人习惯把 std::out_ptr 看作一个「桥梁」。它把C函数需要的 void** 和C++的智能指针连接起来，中间的资源转移完全由标准库帮你搞定。你想想看，这比手动 reset 安全了多少？

30.4 std::inout_ptr：既输入又输出的指针适配器

有些C API更「霸道」——它们不仅会输出新指针，还会读取你传入的旧指针。比如一个重新分配缓冲区的函数：

extern "C" int reallocate_buffer(void** inout_ptr, size_t new_size);

这种场景下，std::out_ptr 就不够用了，因为它只负责输出，不会帮你释放旧资源。这时候得用 std::inout_ptr：

auto deleter = [](void* p) { free_buffer(p); };
std::unique_ptr<void, decltype(deleter)> buf(nullptr, deleter);

// 先分配初始缓冲区
if (create_buffer(std::out_ptr(buf), 512) != 0) {
    return 1;
}

// 重新分配为更大的缓冲区
if (reallocate_buffer(std::inout_ptr(buf), 1024) != 0) {
    return 1;
}

std::inout_ptr 在调用C函数之前，会先 release 智能指针中原来的资源（但不会释放它），然后把旧指针的地址传给C函数。C函数内部可能会 free 旧指针并分配新指针，或者直接原地扩展。调用结束后，std::inout_ptr 会把新指针 reset 回智能指针。

30.5 与 shared_ptr 的配合

这两个适配器不仅支持 unique_ptr，也支持 shared_ptr。不过 shared_ptr 的情况稍微复杂一些，因为它的控制块需要额外处理：

std::shared_ptr<void> shared_buf(nullptr, deleter);

// 使用 shared_ptr 时，out_ptr 会创建一个临时的 shared_ptr
// 并在析构时替换原 shared_ptr 的内容
if (create_buffer(std::out_ptr(shared_buf), 256) != 0) {
    return 1;
}

我个人建议：除非你确实需要共享所有权，否则优先用 unique_ptr。因为 shared_ptr 的 out_ptr 实现会涉及引用计数的增减，性能开销稍大一些。而且从语义上讲，C API 返回的资源通常只有一个所有者，用 unique_ptr 更贴切。

30.6 使用注意事项

虽然这两个工具很好用，但也不是万能的。我总结了几点需要注意的地方：

• 不要重复使用同一个适配器对象：std::out_ptr 和 std::inout_ptr 是临时对象，应该直接在函数调用时构造。不要先声明一个变量再传参。
• 确保删除器匹配：C函数用什么方式释放资源，你的删除器就得对应什么方式。比如C函数用 malloc，你就得用 free；用 fopen，就得用 fclose。
• 注意异常安全：虽然这两个适配器本身是异常安全的，但如果C函数内部抛出了C++异常（比如通过回调），行为是未定义的。C互操作的边界上，最好用 noexcept 包装一下。
• 不要用于非指针资源：这两个适配器只适用于指针类型的输出参数。对于文件描述符、句柄等整型资源，它们帮不上忙。

30.7 知识体系总览

下面这张图梳理了 std::out_ptr 和 std::inout_ptr 的核心逻辑和适用场景：

30.8 总结

std::out_ptr 和 std::inout_ptr 是C++23在C互操作领域迈出的重要一步。它们没有引入什么新概念，而是巧妙地利用了已有的智能指针和RAII机制，把那些容易出错的「指针的指针」操作封装起来。

我在实际项目中的体会是：这两个工具最大的价值不是减少代码量，而是消除了一类特定的内存安全问题。以前每次写 &raw_ptr 的时候，心里都得绷着一根弦——现在终于可以放心地把这个细节交给标准库了。

如果你还在用C++17或更早的标准，可以考虑用 boost::out_ptr 作为替代方案，它的接口和C++23基本一致。等编译器全面支持C++23后，直接切换到标准库版本就行。

---

公众号：蓝海资料掘金营，微信 deep3321