C++unique_ptr与STL容器结合使用技巧

P粉602998670

发布时间：2025-09-03 09:29:01

820人浏览过

来源于php中文网

原创

将unique_ptr与STL容器结合使用，能实现自动内存管理，避免泄漏，提升代码安全与健壮性。通过std::make_unique创建对象并用std::move转移所有权，容器元素的生命周期由unique_ptr自动管理，析构时自动释放资源。访问时使用->或*操作符，并建议先检查指针有效性。该模式遵循RAII原则，明确所有权，提供异常安全保证，且运行时开销极小，是现代C++推荐的最佳实践。

c++unique_ptr与stl容器结合使用技巧

在C++中，将

unique_ptr

与STL容器结合使用，是现代C++内存管理的一种非常推荐且强大的模式。它让我们能够将动态分配的对象的生命周期管理委托给

unique_ptr

，同时利用STL容器强大的数据组织能力，从而有效地避免内存泄漏，简化资源管理，并提升代码的健壮性。简而言之，就是用智能指针来“拥有”容器里的动态对象，让内存管理变得自动化且安全。

解决方案

要将

unique_ptr

与STL容器结合使用，核心思想是将

unique_ptr

作为容器的元素类型。这意味着容器不再直接存储裸指针，而是存储这些智能指针。例如，如果你想存储一系列动态创建的

MyObject

对象，你会声明一个

std::vector>

，而不是

std::vector

。

当我们向容器中添加元素时，通常会使用

std::make_unique

来创建对象，然后通过

std::move

将其所有权转移到容器中的

unique_ptr

。这是因为

unique_ptr

是独占所有权的，它不允许被拷贝，只能被移动。当容器中的

unique_ptr

被销毁（例如，容器本身被销毁，或者元素被从容器中移除），它所指向的动态对象也会被自动删除，无需手动调用

delete

。这极大地简化了复杂的内存管理，尤其是在处理异常或者容器元素生命周期不确定时。

举个例子：

立即学习“C++免费学习笔记（深入）”；

#include 
#include  // For std::unique_ptr and std::make_unique
#include 

class MyResource {
public:
    int id;
    MyResource(int _id) : id(_id) {
        std::cout << "MyResource " << id << " created.\n";
    }
    ~MyResource() {
        std::cout << "MyResource " << id << " destroyed.\n";
    }
    void do_something() const {
        std::cout << "MyResource " << id << " doing something.\n";
    }
};

int main() {
    // 创建一个存储unique_ptr的vector
    std::vector> resources;

    // 向容器中添加元素
    // 使用std::make_unique创建对象，并通过std::move转移所有权
    resources.push_back(std::make_unique(1));
    resources.push_back(std::make_unique(2));

    // 访问容器中的元素
    for (const auto& res_ptr : resources) {
        if (res_ptr) { // 检查指针是否有效
            res_ptr->do_something();
        }
    }

    // 从容器中移除元素，其所指对象会被自动销毁
    if (!resources.empty()) {
        std::cout << "Removing first resource...\n";
        resources.erase(resources.begin());
    }

    // 当main函数结束，resources容器被销毁时，剩余的unique_ptr也会被销毁，
    // 从而自动删除它们所管理的对象。
    std::cout << "Main function ending.\n";
    return 0;
}

运行这段代码，你会看到

MyResource

对象的创建和销毁都发生在预期的时间点，无需手动干预。

为什么在STL容器中使用unique_ptr管理动态对象是最佳实践？

我认为，将

unique_ptr

与STL容器结合，不仅仅是一种“技巧”，它更是现代C++中处理动态资源管理的一种“范式转变”。这种模式的优势是多方面的，并且解决了传统裸指针容器带来的诸多痛点。

首先，最核心的便是RAII（Resource Acquisition Is Initialization）原则的完美体现。

unique_ptr

天生就是为RAII而生，它确保了在对象生命周期结束时，其所管理的资源（内存）能够被自动释放。当我们将

unique_ptr

放入STL容器时，容器元素的生命周期管理就自动继承了

unique_ptr

的RAII特性。这意味着，无论容器何时被销毁（例如，超出作用域），或者容器中的某个元素被移除，相应的

unique_ptr

都会被正确销毁，进而触发它所管理对象的析构函数，从而彻底杜绝了内存泄漏的风险。这在面对复杂的控制流、异常处理或者多线程环境时，其价值尤为凸显。手动管理裸指针的容器，哪怕只是一点点疏忽，都可能导致灾难性的内存泄漏。

其次，所有权语义变得异常清晰。

unique_ptr

明确表达了“独占所有权”的概念，即一个对象在任何时刻只能被一个

unique_ptr

所拥有。这种独占性通过禁用拷贝构造函数和赋值运算符来强制执行，只允许通过移动语义（

std::move

）来转移所有权。当容器中存储

unique_ptr

时，这也就意味着容器“拥有”了这些动态对象。这种清晰的所有权模型极大地简化了代码的理解和维护。我们不再需要猜测谁负责

delete

一个对象，因为答案就在类型本身中。这与裸指针容器形成了鲜明对比，裸指针容器中的指针可能只是一个观察者，也可能是一个所有者，模糊不清的所有权是许多bug的根源。

再者，它提供了强大的异常安全保证。考虑一个向容器中插入多个动态创建对象的场景。如果使用裸指针，在创建了几个对象后，后续的对象创建失败或者其他操作抛出异常，那么之前成功创建的对象可能就无法被正确清理，导致内存泄漏。而

unique_ptr

配合RAII，即使在构造函数抛出异常的情况下，已经成功构造并被

unique_ptr

管理的对象也能被正确销毁，从而保证了资源管理的异常安全。

最后，性能开销几乎可以忽略不计。

unique_ptr

在运行时几乎没有额外的开销，它的大小通常与裸指针相同，并且其操作（如解引用、移动）的性能也与裸指针相当。与

shared_ptr

不同，

unique_ptr

不需要维护引用计数，因此避免了原子操作的开销。这意味着我们可以在享受安全性和便利性的同时，几乎不牺牲性能。这对于那些性能敏感的应用场景来说，是非常重要的一个考量。

所以，从我个人的经验来看，只要你确定一个对象应该被独占所有权，并且它的生命周期需要与容器的元素生命周期绑定，那么

std::vector>

或者

std::map>

就是几乎无可争议的最佳选择。它让代码更安全、更清晰，也更易于维护。

在STL容器中使用unique_ptr时，如何处理所有权转移和元素访问？

处理

unique_ptr

在STL容器中的所有权转移和元素访问，是理解其工作机制的关键。由于

unique_ptr

的独占所有权特性，它不能被简单地拷贝，只能通过

std::move

进行所有权转移。

所有权转移（

std::move

）

当你需要将一个

unique_ptr

所管理的对象放入容器，或者从容器中取出（并转移所有权）时，

std::move

是你的核心工具。

向容器中添加元素： 通常，你会创建一个临时的

unique_ptr

，然后使用

std::move

将其所有权转移到容器中。这通常发生在

push_back

、

insert

、

emplace_back

等操作中。

std::vector> resources;
// 方式一：直接创建并移动
resources.push_back(std::make_unique(3)); 

// 方式二：先创建，再移动
auto temp_ptr = std::make_unique(4);
resources.push_back(std::move(temp_ptr)); // temp_ptr 在这之后就为空了
// std::cout << temp_ptr.get(); // 输出0x0，证明已为空

// 对于map或set等关联容器
std::map> resource_map;
resource_map.emplace(5, std::make_unique(5)); // emplace通常更高效
resource_map.insert({6, std::make_unique(6)}); // 也可以这样

值得注意的是，

std::make_unique

本身返回一个右值引用，所以直接

push_back(std::make_unique(...))

就隐式地完成了移动。如果先创建了一个具名

unique_ptr

变量，那么你需要显式地使用

std::move

。

从容器中取出元素并转移所有权： 如果你需要从容器中“取出”一个元素，并且希望外部代码接管其所有权，同样需要使用
```
std::move
```
。一旦所有权被转移，容器中对应位置的
```
unique_ptr
```
就会变为空（
```
nullptr
```
）。
```
std::unique_ptr extracted_resource = std::move(resources[0]);
// 此时 resources[0] 变为空指针
if (resources[0] == nullptr) {
    std::cout << "resources[0] is now null.\n";
}
extracted_resource->do_something(); // 可以正常使用 extracted_resource
```
这种操作在设计工厂函数或者需要将容器中的对象“弹出”并交给其他模块管理时非常有用。

*元素访问（

->

和``）**

知鹿匠

知鹿匠教师AI工具，新课标教案_AI课件PPT_作业批改

下载

访问

unique_ptr

所管理的对象，与访问普通指针非常相似，主要通过解引用运算符（

）和成员访问运算符（

->

）。

通过索引或迭代器访问： 无论是

std::vector

、

std::deque

还是其他支持随机访问的容器，你都可以通过索引来获取

unique_ptr

，然后解引用。对于所有STL容器，迭代器是通用的访问方式。

// 向量通过索引访问
if (resources[0]) { // 最好先检查是否为空
    resources[0]->do_something(); // 使用 -> 访问成员函数
    std::cout << "ID: " << (*resources[0]).id << "\n"; // 使用 * 解引用后访问成员
}

// 迭代器访问
for (auto it = resource_map.begin(); it != resource_map.end(); ++it) {
    if (it->second) { // map的value是unique_ptr
        it->second->do_something();
    }
}

// C++11 range-based for loop
for (const auto& res_ptr : resources) { // 注意这里是 const auto&，避免不必要的移动
    if (res_ptr) {
        res_ptr->do_something();
    }
}

务必记住，在解引用

unique_ptr

之前，检查它是否为空是一个好习惯，尽管在大多数情况下，如果你正确地管理了所有权，容器中的

unique_ptr

应该都是有效的。但如果之前有进行过所有权转移操作，或者某些逻辑可能导致

unique_ptr

为空，那么这个检查就变得很重要。

总结来说，

std::move

是你在STL容器中与

unique_ptr

打交道的核心，它确保了所有权的正确转移，而

->

和

则让你能够像操作普通指针一样访问底层对象。理解并熟练运用这些机制，是高效使用

unique_ptr

与STL容器的关键。

使用unique_ptr和STL容器时常见的陷阱与性能考量？

即便

unique_ptr

和STL容器的组合非常强大，但在实际使用中，我们仍然会遇到一些陷阱，并且需要对性能有一些基本的考量。这些往往不是

unique_ptr

本身的缺陷，而是使用方式不当或者对C++语义理解不够深入导致的。

常见的陷阱：

忘记

std::move

：这是最常见也最容易犯的错误。

unique_ptr

是独占所有权的，它禁止拷贝。如果你尝试不通过

std::move

就将一个具名的

unique_ptr

变量赋值给另一个

unique_ptr

，或者直接

push_back

到一个容器中，编译器会报错。

std::unique_ptr p1 = std::make_unique(7);
// std::unique_ptr p2 = p1; // 编译错误：call to deleted constructor
// resources.push_back(p1); // 编译错误：call to deleted constructor
resources.push_back(std::move(p1)); // 正确

记住，只有右值（例如

std::make_unique

的返回值或者

std::move

的返回结果）才能直接用于构造或赋值

unique_ptr

。

混合裸指针与智能指针： 当你的代码库同时存在裸指针和智能指针时，很容易导致所有权混乱。例如，你从一个
```
unique_ptr
```
中获取了裸指针（通过
```
get()
```
），然后又尝试手动
```
delete
```
这个裸指针。这会导致双重释放（double free），因为
```
unique_ptr
```
在其生命周期结束时也会尝试
```
delete
```
它所管理的对象。
```
std::unique_ptr p = std::make_unique(8);
MyResource* raw_p = p.get();
// delete raw_p; // 绝对不要这样做！会导致双重释放
```
一旦资源由
```
unique_ptr
```
管理，就应尽可能避免直接操作其裸指针，除非你非常清楚你在做什么，并且确保不会干预
```
unique_ptr
```
的生命周期管理。
在容器中存储
```
unique_ptr
```
的引用或裸指针： 这是一个微妙但重要的陷阱。如果你创建了一个
```
std::vector>
```
，然后又创建了一个
```
std::vector
```
或
```
std::vector
```
，并试图让后者存储前者的元素。
```
std::vector> smart_resources;
smart_resources.push_back(std::make_unique(9));

// 错误的做法：存储裸指针，当smart_resources元素被移除或smart_resources销毁时，这些裸指针会悬空
std::vector raw_pointers;
raw_pointers.push_back(smart_resources[0].get()); 
// 此时如果smart_resources[0]被移除或smart_resources超出作用域，raw_pointers[0]就成了悬空指针
```
如果确实需要一个辅助容器来“观察”智能指针管理的对象，那么存储裸指针是可行的，但你必须清楚地知道这些裸指针的生命周期完全依赖于原始的智能指针容器。一旦原始容器中的智能指针被销毁，对应的裸指针就失效了。
不当的自定义删除器：
```
unique_ptr
```
支持自定义删除器，这在管理非内存资源（如文件句柄、互斥锁）时非常有用。但如果删除器定义不正确，或者与资源类型不匹配，就可能导致资源泄漏或崩溃。

性能考量：

```
std::make_unique
```
的优势： 始终优先使用
```
std::make_unique
```
来创建
```
unique_ptr
```
。它比直接使用
```
new
```
然后传递给
```
unique_ptr
```
构造函数更安全、更高效。
- 异常安全：
```
std::make_unique
```
  进行单次内存分配。如果使用
```
new MyObject()
```
  和
```
unique_ptr(raw_ptr)
```
  ，在
```
new
```
  和
```
unique_ptr
```
  构造之间，如果另一个函数调用抛出异常，
```
raw_ptr
```
  可能无法被
```
unique_ptr
```
  捕获，导致内存泄漏。
```
make_unique
```
  消除了这种风险。
- 效率： 避免了两次内存分配（一次是对象本身，一次是
```
unique_ptr
```
  的内部状态，虽然
```
unique_ptr
```
  本身通常不需要额外分配，但对于
```
shared_ptr
```
  来说这个优势更明显）。
```
unique_ptr
```
本身的开销： 如前所述，
```
unique_ptr
```
在运行时几乎没有额外的开销。它的大小通常与裸指针相同，并且其操作（解引用、移动）的性能与裸指针相当。这是它优于
```
shared_ptr
```
的一个显著特点，后者需要额外的引用计数开销。
容器操作的开销：
- std::vector
  的重新分配：当
```
std::vector
```
  增长并需要重新分配内存时，所有存储的
```
unique_ptr
```
  都需要被移动到新的内存位置。虽然`unique_ptr