C++智能指针 unique_ptr使用指南-C++-PHP中文网

unique_ptr通过独占所有权和RAII原则，确保动态资源在作用域结束时自动释放，避免内存泄漏、双重释放和异常安全问题；使用std::make_unique可保证异常安全并简化代码；其移动语义支持所有权转移，适用于函数返回、参数传递和容器存储，提升代码安全与效率。

c++智能指针 unique_ptr使用指南

C++的

unique_ptr

登录后复制

是一个智能指针，它赋予了动态分配对象“独占”所有权的能力。简单来说，它确保了一块堆内存资源在同一时间只有一个拥有者，并且当这个

unique_ptr

登录后复制

对象本身的生命周期结束时，它会自动、安全地释放所持有的内存，有效杜绝了内存泄漏和悬空指针等常见问题。它就是C++现代内存管理中，避免手动

delete

登录后复制

、拥抱RAII（资源获取即初始化）原则的利器。

解决方案

使用

unique_ptr

登录后复制

，最核心的思路就是将动态分配的资源绑定到一个栈上的对象，让这个栈对象在超出作用域时自动清理资源。

1. 创建

unique_ptr

登录后复制

：最推荐也最安全的做法是使用

std::make_unique

登录后复制

。它不仅代码更简洁，还能提供异常安全保障。

#include <memory>
#include <iostream>

class MyObject {
public:
    MyObject() { std::cout << "MyObject created\n"; }
    ~MyObject() { std::cout << "MyObject destroyed\n"; }
    void doSomething() { std::cout << "Doing something...\n"; }
};

// 使用 std::make_unique 创建
std::unique_ptr<MyObject> ptr1 = std::make_unique<MyObject>();
// 也可以直接在声明时初始化
// auto ptr2 = std::make_unique<MyObject>(); // C++14 以后

登录后复制

避免直接使用

new

登录后复制

来初始化，尽管这也是可以的，但存在异常安全隐患（后面会详细解释）。

// 不推荐，但可以工作
std::unique_ptr<MyObject> ptr_bad_practice(new MyObject());

登录后复制

2. 访问所指向的对象： 和原始指针一样，可以使用解引用运算符

登录后复制

和成员访问运算符

->

登录后复制

来访问

unique_ptr

登录后复制

指向的对象。

ptr1->doSomething(); // 调用 MyObject 的成员函数
(*ptr1).doSomething(); // 另一种方式

登录后复制

如果你需要获取原始指针（通常是为了与C风格API交互，但请谨慎使用，因为这可能绕过智能指针的安全性），可以使用

get()

登录后复制

方法。

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

MyObject* rawPtr = ptr1.get();
if (rawPtr) {
    rawPtr->doSomething();
}

登录后复制

3. 转移所有权：

unique_ptr

登录后复制

是“独占”的，意味着它不能被复制。但它可以通过移动语义（

std::move

登录后复制

）来转移所有权。当所有权转移后，原来的

unique_ptr

登录后复制

将不再指向任何对象（变为

nullptr

登录后复制

）。

std::unique_ptr<MyObject> ptrA = std::make_unique<MyObject>();
std::unique_ptr<MyObject> ptrB = std::move(ptrA); // 所有权从 ptrA 转移到 ptrB

if (ptrA) { // ptrA 现在是空的
    std::cout << "ptrA still holds an object.\n";
} else {
    std::cout << "ptrA is now empty.\n"; // 会打印这行
}

ptrB->doSomething(); // ptrB 现在拥有对象

登录后复制

这种转移所有权的能力在函数返回、或者将对象放入容器时非常有用。

4. 释放或重置：

reset()

登录后复制

：释放当前

unique_ptr

登录后复制

所持有的对象，并使其指向

nullptr

登录后复制

。你也可以传入一个新的原始指针，让它接管新的对象。

std::unique_ptr<MyObject> ptrC = std::make_unique<MyObject>();
ptrC.reset(); // MyObject 被销毁，ptrC 变空
ptrC.reset(new MyObject()); // 销毁旧对象（如果存在），接管新对象

登录后复制

```
release()
```
登录后复制
：放弃对当前对象的管理权，返回其原始指针，但不会销毁对象。这意味着你必须手动管理这个返回的原始指针，否则会导致内存泄漏。
```
std::unique_ptr<MyObject> ptrD = std::make_unique<MyObject>();
MyObject* releasedPtr = ptrD.release(); // ptrD 变空，MyObject 未被销毁
// 此时，你必须手动 delete releasedPtr
delete releasedPtr;
```
登录后复制
```
release()
```
登录后复制
是一个相对危险的操作，通常只在需要将所有权传递给不接受智能指针的C风格API时使用，并且要非常小心后续的内存管理。

5. 自定义删除器（Custom Deleter）：

unique_ptr

登录后复制

默认使用

delete

登录后复制

运算符来释放内存。但如果你分配的资源不是通过

new

登录后复制

获得的（比如文件句柄、C风格的

malloc

登录后复制

分配的内存、或者需要特殊清理函数的资源），你可以提供一个自定义的删除器。

// 示例：自定义删除器，用于关闭文件句柄
struct FileCloser {
    void operator()(FILE* fp) const {
        if (fp) {
            fclose(fp);
            std::cout << "File closed.\n";
        }
    }
};

// 使用 unique_ptr 管理 FILE*
std::unique_ptr<FILE, FileCloser> filePtr(fopen("example.txt", "w"));
if (filePtr) {
    fputs("Hello, unique_ptr!\n", filePtr.get());
    // 文件会在 filePtr 超出作用域时自动关闭
}

登录后复制

自定义删除器可以是函数指针、函数对象或Lambda表达式。这让

unique_ptr

登录后复制

不仅能管理内存，还能管理任何需要RAII模式的资源。

unique_ptr

登录后复制

与裸指针相比，它解决了哪些核心问题？

在我看来，

unique_ptr

登录后复制

最根本的价值在于它将资源管理从程序员的显式操作中解放出来，内化到了类型系统里。想想看，我们用裸指针

new

登录后复制

一个对象，就得记得在某个地方

delete

登录后复制

它，这就像签了一份合同，但合同的解除条款全凭自觉。一旦忘记，或者在复杂的逻辑分支、异常抛出时没有正确执行

delete

登录后复制

，内存泄漏就成了家常便饭。这不仅是性能问题，更是稳定性隐患。

unique_ptr

登录后复制

通过RAII（Resource Acquisition Is Initialization）原则，优雅地解决了以下几个让人头疼的核心问题：

内存泄漏的终结者： 这是最直接、最显著的优点。
```
unique_ptr
```
登录后复制
在构造时获取资源（通过
```
new
```
登录后复制
或
```
make_unique
```
登录后复制
），在析构时自动释放资源。无论函数是正常返回，还是因为异常提前退出，只要
```
unique_ptr
```
登录后复制
对象超出作用域，其析构函数就会被调用，从而安全地释放它所拥有的内存。这意味着你再也不用在代码中到处散布
```
delete
```
登录后复制
语句，大大降低了出错的概率。对我个人而言，这简直是解放生产力。
双重释放（Double Deletion）的预防： 裸指针的另一个陷阱是，如果同一个内存地址被
```
delete
```
登录后复制
了两次，程序行为就会变得未定义，轻则崩溃，重则数据损坏。
```
unique_ptr
```
登录后复制
的独占所有权特性从根本上杜绝了这个问题。一个
```
unique_ptr
```
登录后复制
拥有一个对象，当所有权转移后，原
```
unique_ptr
```
登录后复制
就变成了空，不可能再对它进行二次删除。这种清晰的所有权模型，让代码逻辑变得更加可预测。
异常安全性的提升： 想象一下，在一个函数中，你
```
new
```
登录后复制
了一个对象，然后又调用了几个可能抛出异常的函数，最后才
```
delete
```
登录后复制
。如果中间的函数抛出异常，
```
delete
```
登录后复制
语句可能永远不会执行到，导致内存泄漏。
```
unique_ptr
```
登录后复制
则不然，由于它在栈上，无论是否发生异常，其析构函数总会被调用，从而保证资源的正确释放，确保了代码的异常安全性。这在编写健壮的现代C++程序时至关重要。

Gnomic智能体平台
国内首家无需魔法免费无限制使用的ChatGPT4.0，网站内设置了大量智能体供大家免费使用，还有五款语言大模型供大家免费使用~

47

查看详情
所有权语义的明确： 当函数参数或返回值是裸指针时，我们很难一眼看出这个指针的所有权归属：是调用者负责释放？还是被调用者负责释放？
```
unique_ptr
```
登录后复制
则通过其类型本身就清晰地表达了“独占所有权”的语义。如果一个函数接收
```
unique_ptr
```
登录后复制
作为参数，通常意味着它将接管这个对象的所有权；如果一个函数返回
```
unique_ptr
```
登录后复制
，则意味着它将所有权转移给调用者。这种显式的语义，让代码意图更加清晰，减少了沟通成本和潜在的误解。

这些问题，在传统的C++编程中，往往需要大量的约定、注释和严谨的代码审查来避免。而

unique_ptr

登录后复制

的引入，直接将这些最佳实践固化到了语言特性中，让我觉得写出的代码天然就更安全、更健壮。

在实际项目中，什么时候应该优先考虑使用

std::make_unique

登录后复制

而不是直接

new

登录后复制

？

在现代C++编程中，我几乎可以毫不犹豫地说：总是优先考虑

std::make_unique

登录后复制

（或
std::make_shared
登录后复制
），而不是直接使用
new
登录后复制
来初始化智能指针。这不仅仅是代码风格的问题，它背后有实实在在的技术考量，尤其是在异常安全方面。

让我们看一个经典的例子来理解其中的差异。假设你有一个函数

process(std::unique_ptr<A> a, std::unique_ptr<B> b)

登录后复制

，并且你打算这样调用它：

// 场景一：使用 new
process(std::unique_ptr<A>(new A()), std::unique_ptr<B>(new B()));

// 场景二：使用 make_unique
process(std::make_unique<A>(), std::make_unique<B>());

登录后复制

在场景一中，编译器在执行

process

登录后复制

函数之前，需要评估其参数。C++标准并没有严格规定函数参数的评估顺序，这意味着

new A()

登录后复制

、

new B()

登录后复制

和

std::unique_ptr

登录后复制

的构造函数这几个操作的执行顺序是不确定的。一个可能的执行顺序是：

执行
```
new A()
```
登录后复制
执行
```
new B()
```
登录后复制
构造
```
std::unique_ptr<A>
```
登录后复制
构造
```
std::unique_ptr<B>
```
登录后复制

问题就出在这里。如果

new A()

登录后复制

成功了，但在执行

new B()

登录后复制

的过程中抛出了异常（比如内存不足），那么

new A()

登录后复制

返回的那个裸指针将永远没有机会被

std::unique_ptr<A>

登录后复制

接管，因为

std::unique_ptr<A>

登录后复制

的构造函数还没来得及被调用。结果就是：内存泄漏。这是一种微妙但非常危险的异常安全问题。

而场景二，使用

std::make_unique

登录后复制

时，它会一次性完成对象的创建和

unique_ptr

登录后复制

的构造。

std::make_unique<A>()

登录后复制

是一个原子操作，它要么成功返回一个完全构造好的

unique_ptr

登录后复制

，要么在内部抛出异常而不会有任何裸指针泄露。因此，即使在

std::make_unique<B>()

登录后复制

抛出异常时，

std::make_unique<A>()

登录后复制

已经安全地将资源封装在了智能指针中，当

process

登录后复制

函数调用失败时，这个

unique_ptr

登录后复制

也会被正确析构，释放资源。

除了异常安全，

std::make_unique

登录后复制

还有其他一些优点：

简洁性： 代码更短，更易读，尤其是当构造函数有多个参数时。
避免重复类型名： 你不需要在
```
<>
```
登录后复制
中和
```
()
```
登录后复制
中都写上类型名，减少了冗余。
性能（对
shared_ptr
登录后复制
更明显）：对于
```
shared_ptr
```
登录后复制
，
```
std::make_shared
```
登录后复制
可以只进行一次内存分配，同时为对象本身和控制块分配内存，这比先
```
new
```
登录后复制
对象再
```
new
```
登录后复制
控制块更高效。虽然对于
```
unique_ptr
```
登录后复制
，这个性能优势不那么明显，因为它没有控制块，但它保持了与
```
shared_ptr
```
登录后复制
一致的推荐用法。

所以，我的建议是，除非你真的有非常特殊的原因（比如需要自定义分配器，而

make_unique

登录后复制

不支持），否则在任何需要创建

unique_ptr

登录后复制

的地方，都应该毫不犹豫地选择

std::make_unique

登录后复制

。这是一种良好的编程习惯，能让你的代码更健壮、更安全。

unique_ptr

登录后复制

的移动语义在复杂数据结构或函数参数传递中如何体现其优势？

unique_ptr

登录后复制

的移动语义是其核心特性之一，它完美地诠释了“独占所有权”的概念，并在实际编程中带来了巨大的灵活性和效率。简单来说，移动语义允许你将一个

unique_ptr

登录后复制

所拥有的资源“搬走”，而不是“复制”它。这在处理复杂数据结构或进行函数间所有权转移时，其优势表现得淋漓尽致。

1. 函数返回

unique_ptr

登录后复制

以转移所有权： 这是最常见的场景之一。当一个函数负责创建并初始化一个动态对象，然后将这个对象的管理权移交给调用者时，返回

unique_ptr

登录后复制

是最佳实践。

std::unique_ptr<MyObject> createMyObject() {
    // 假设这里有一些复杂的初始化逻辑
    std::cout << "Creating object inside function...\n";
    return std::make_unique<MyObject>(); // 返回一个 unique_ptr
}

int main() {
    std::unique_ptr<MyObject> obj = createMyObject(); // 所有权从函数内部转移到 main
    obj->doSomething();
    // main 函数结束时，obj 会自动销毁 MyObject
    return 0;
}

登录后复制

在这里，

createMyObject

登录后复制

函数内部创建的

MyObject

登录后复制

实例，其所有权通过

unique_ptr

登录后复制

的移动构造函数（隐式发生，由RVO/NRVO优化）安全、高效地转移给了

main

登录后复制

函数中的

obj

登录后复制

。如果返回裸指针，调用者就得自己

delete

登录后复制

，增加了风险；如果返回值是值类型，又会涉及到不必要的深拷贝（如果

MyObject

登录后复制

可拷贝且很重）。移动语义在这里提供了一个零开销且安全的解决方案。

2. 将

unique_ptr

登录后复制

作为函数参数，表示所有权转移： 当一个函数需要接管一个动态对象的所有权，并可能在函数内部对其进行管理、修改或最终销毁时，可以通过

std::move

登录后复制

将

unique_ptr

登录后复制

传入。

void takeOwnership(std::unique_ptr<MyObject> obj) {
    if (obj) {
        std::cout << "Function received ownership, doing something...\n";
        obj->doSomething();
        // 函数结束时，obj 会自动销毁 MyObject
    }
}

int main() {
    std::unique_ptr<MyObject> myObj = std::make_unique<MyObject>();
    takeOwnership(std::move(myObj)); // 显式移动所有权
    // 此时 myObj 已经为空
    if (!myObj) {
        std::cout << "Original unique_ptr is now empty.\n";
    }
    return 0;
}

登录后复制

这种方式明确地表达了函数

takeOwnership

登录后复制

将接管

myObj

登录后复制

所指向的对象，原

myObj

登录后复制

将不再拥有该对象。这种语义的清晰度，远超传递裸指针。

3. 在容器中存储动态对象：

std::vector<std::unique_ptr<T>>

登录后复制

是一个非常强大的模式，它允许你在容器中存储动态创建的对象，并且这些对象的生命周期由容器中的

unique_ptr

登录后复制

来管理。

#include <vector>

int main() {
    std::vector<std::unique_ptr<MyObject>> objects;

    objects.push_back(std::make_unique<MyObject>()); // 移动构造
    objects.emplace_back(); // 直接在容器中构造 MyObject，然后用 unique_ptr 封装

    // 假设我们想添加一个已经存在的 unique_ptr
    std::unique_ptr<MyObject> anotherObj = std::make_unique<MyObject>();
    objects.push_back(std::move(anotherObj)); // 显式移动所有权

    for (const auto& ptr : objects) {
        if (ptr) {
            ptr->doSomething();
        }
    }
    // 当 vector 超出作用域时，其中所有的 unique_ptr 都会被销毁，
    // 进而销毁它们所指向的 MyObject 实例。
    return 0;
}

登录后复制

这种方式避免了在容器中存储原始指针可能导致的内存泄漏问题，也避免了存储值类型对象可能带来的不必要的拷贝开销（如果

MyObject

登录后复制

很大）。它使得管理一组动态分配的对象变得非常简洁和安全。

总结一下，

unique_ptr

登录后复制

的移动语义带来了：

零开销的所有权转移： 避免了不必要的深拷贝，尤其是在对象很大时，效率非常高。
清晰的语义表达： 代码阅读者一眼就能明白资源的所有权是如何在不同代码块之间流转的。
编译时安全检查： 由于
```
unique_ptr
```
登录后复制
不可复制，任何尝试复制它的行为都会导致编译错误，这强制你思考所有权问题，从而避免了许多运行时错误。

可以说，移动语义是