为何std::unique_ptr的reset与赋值行为不同？直接赋值new对象为何失效？

这个问题问到了std::unique_ptr设计的核心——对独占所有权的严格管控，咱们一步步来拆解：

1. 直接赋值失败的核心原因：explicit构造函数 #

std::unique_ptr从原始指针构造的构造函数被声明为explicit：

explicit unique_ptr(pointer p) noexcept;

在C++中，当你写std::unique_ptr<MyClass> p = new MyClass;时，这属于拷贝初始化，要求从右侧的MyClass*隐式转换为std::unique_ptr<MyClass>。但explicit修饰的构造函数会禁止这种隐式转换，所以编译器会直接报错。

而p.reset(new MyClass);是直接调用成员函数reset，它的参数本身就是原始指针，不需要任何类型转换，自然可以正常执行。

顺带提一句：如果你用直接初始化的方式，是可以编译通过的：

std::unique_ptr<MyClass> p(new MyClass); // 没问题，因为是直接调用explicit构造函数

2. 这样设计的初衷：避免意外的所有权转移 #

unique_ptr的本质是独占式智能指针——同一时间只能有一个unique_ptr拥有对对象的所有权，指针销毁时会自动释放对象。如果允许从原始指针隐式转换为unique_ptr，很容易出现开发者无意识的所有权变更，比如：

• 假设你有一个函数：

  void process_data(std::unique_ptr<MyClass> obj) { /* ... */ }
  

  如果允许隐式转换，开发者可能会不小心写process_data(new MyClass);，看起来只是传了个指针，但实际上obj会悄悄接管这个对象的所有权。函数执行完毕后obj销毁，对象被释放；如果开发者之后还想使用这个原始指针（比如保存了副本），就会触发悬空指针或双重释放的未定义行为。

• 再比如，开发者可能会误写：

  MyClass* raw_ptr = new MyClass;
  std::unique_ptr<MyClass> smart_ptr = raw_ptr; // 如果允许隐式转换，这里会悄悄转移所有权
  delete raw_ptr; // 双重释放！
  

把构造函数设为explicit，就是强迫开发者明确表达“我要把原始指针的所有权转移给unique_ptr”，比如用直接初始化或者reset，从根源上减少这类低级错误。

3. 若让赋值与reset行为一致的风险 #

如果允许std::unique_ptr<MyClass> p = new MyClass;这种隐式转换，会带来两个核心风险：

（1）无意识的所有权转移导致内存错误 #

如上面的例子，开发者可能没意识到自己已经把原始指针的所有权交给了unique_ptr，后续对原始指针的操作（比如手动delete、继续访问）都会触发未定义行为，这类问题往往很难排查。

（2）异常安全隐患 #

假设你写了这样的代码：

func(std::unique_ptr<MyClass>(new MyClass), risky_function());

C++的函数参数求值顺序是未定义的，如果编译器先执行new MyClass，再执行risky_function()，而risky_function()抛出了异常，那么new MyClass返回的指针就会泄漏——因为unique_ptr还没来得及构造，无法接管所有权。

而如果用std::make_unique（C++14及以上），就不会有这个问题：

func(std::make_unique<MyClass>(), risky_function());

make_unique会一次性完成对象的构造和unique_ptr的初始化，是原子性的操作，即使risky_function()抛出异常，也不会泄漏内存。

更推荐的写法 #

其实不管是reset还是直接初始化，都不如std::make_unique来得安全简洁：

auto p = std::make_unique<MyClass>();

它不仅避免了手动写new，还解决了上面提到的异常安全问题，是C++标准库推荐的unique_ptr创建方式。

内容的提问来源于stack exchange，提问作者starmole