PAYATHON 2026

std::vector<T>::data() 是否保证返回 allocator 的原始分配指针？

数据阿明

不能保证。C++ 标准没有规定 std::vector<T>::data() 返回 allocator 的原始分配指针，所以直接调用 get_allocator().deallocate(data(), capacity()) 没有可移植的正确性保证。对于 union 中仍处于活动状态的 vector，应显式调用 vector 自身的析构函数。

data() 保证了什么？

对于非空 vector，标准保证：

v.data() == std::addressof(v.front())

并且 [v.data(), v.data() + v.size()) 是有效范围。这些规定描述了元素的访问地址，没有规定该地址必须等于底层分配操作返回的地址。参见标准草案中的 vector.data。

元素连续存储也不能说明首元素一定在整个分配块的起始位置。例如，假设分配块前面留有额外空间，元素从后面开始，元素连续性要求本身并不排除这种布局。这只是用来说明约束范围，并非声称某个标准库实际采用了这种布局。

同样，capacity() 表示无需重新分配即可容纳的元素数量；其定义没有承诺它等于内部某次 allocate() 的实参。参见vector.capacity。

为什么不能直接调用 deallocate()？

对于通过 allocate(n) 获得的分配，deallocate(p, n) 要求传入对应的分配指针，以及当时请求的元素数量。通过 allocate_at_least() 获得的分配另有数量范围规则，但仍要求使用其返回的分配指针。参见默认 allocator 的释放前置条件。

下面的代码依赖两个 vector 公共接口没有保证的条件：

test.v.get_allocator().deallocate(
    test.v.data(),
    test.v.capacity()
);
  • test.v.data() 恰好是对应分配操作返回的指针。
  • test.v.capacity() 满足该次分配所要求的释放数量条件。

取得正确的 allocator 也不能保证这两个条件成立。即使某个实现恰好满足它们，手动释放仍可能遗漏容器内部需要清理的其他资源。标准对容器析构的要求是销毁所有元素，并释放获得的内存。参见容器析构要求。

int 无需执行有实际效果的析构操作。即使省去元素析构方面的工作，也不能证明上述释放方式正确。

原代码中的 union 析构函数还需要区分标准版本

按 C++23 的规则，union 含有具有非平凡析构函数的成员时，其 defaulted 析构函数会被定义为 deleted。因此，原代码中的：

~test_t() = default;

不能让完整示例在 C++23 下成为合法程序。std::vector<int> 具有非平凡析构函数，而局部变量 test 离开作用域时需要调用 test_t 的析构函数。参见C++23 草案的 class.dtor。

较新的标准草案调整了 union 的相关规则，不能把上述删除条件无差别地套用到所有标准版本。无论采用哪个版本，union 都不会自动完成活动 vector 成员的析构工作。参见现行草案的析构规则。

如何正确地显式释放？

可以为 union 提供一个空析构函数，再在确定 v 是活动成员时显式调用它的析构函数：

#include <utility>
#include <vector>

using vector_t = std::vector<int>;

union test_t {
    vector_t v;
    ~test_t() {}
};

int main() {
    vector_t v = { 1, 2, 3, 4 };
    test_t test { std::move(v) };

    test.v.~vector_t();

    return 0;
}

这里通过类型别名 vector_t 调用析构函数，让 vector 自己处理元素销毁、allocator 和内存释放。union 退出作用域时执行空析构函数，不会再次析构该成员。

这种手动管理方式要求每条执行路径都正确安排清理。如果设计上保证 union 析构时 v 始终是活动成员，也可以在 union 析构函数中直接清理：

~test_t() {
    v.~vector_t();
}

采用后一种方式后，就不要再从外部显式析构 v。如果将来为 union 增加其他成员，或允许没有活动成员，就需要记录活动状态并据此清理。

Rust/C++ FFI 中怎样安排所有权？

可以在 C++ 一侧保留 vector 的所有权，通过 C ABI 提供释放入口，由 Rust 在约定时机调用。该入口在 C++ 一侧执行 vector 的析构，避免 Rust 根据 data() 和 capacity() 推测释放所需的信息。

接口需要明确 Rust 获得的是借用的数据地址还是拥有资源的句柄、借用何时失效，以及哪一方负责最终释放。移动构造后，本例需要清理的对象是 test.v；原来的 v 仍会在作用域结束时正常析构。

显式析构必须恰好执行一次。析构之后，不得继续访问该 vector 或其元素；再次使用对应的 union 成员前，必须重新构造对象。

备注：内容仅供参考。