关于cppreference中std::unique_ptr移动操作是否存在UB的问询

你的推理存在核心误解，cppreference中的List析构代码是完全符合标准、无未定义行为的，具体拆解如下：

核心错误点：对unique_ptr移动赋值逻辑的误解 #

你误以为reset(other.release())会销毁other所持有的对象，但实际逻辑完全相反：

• other.release()的作用是让other放弃对内部指针的所有权，返回原始指针，同时将other的内部指针置空——此时other不再持有任何对象，但other本身是一个完整有效的对象，它的deleter成员并没有失效。
• reset(p)的作用是销毁**当前unique_ptr（即赋值操作的左侧对象）**之前持有的旧资源（如果有的话），然后接管p的所有权，和other原来的对象没有任何关系。

移动赋值运算符的标准执行顺序 #

unique_ptr的移动赋值运算符（针对可移动的deleter）的标准执行步骤是安全的：

1. 调用other.release()获取源指针，同时将other的内部指针置空；
2. 用获取到的指针调用this->reset(p)，销毁当前对象的旧资源并接管新指针；
3. 将other的deleter移动到当前对象中。

这一步中，other的deleter是完全有效的，因为other对象本身还存在（只是内部指针为空），不存在所谓的"悬垂引用"问题。

分情况讨论deleter的影响 #

• 默认无状态deleter（std::default_delete<T>）：这种deleter不存储任何状态，移动操作本质上是无操作，无论执行顺序如何都不会有问题，完全不存在悬垂引用的可能。
• 有状态自定义deleter：只要deleter符合可移动要求，标准规定的移动赋值顺序就能保证安全——因为转移deleter时，other的deleter成员仍然是完整有效的，不会出现访问悬垂引用的情况。

回到cppreference的示例代码 #

示例中的循环逻辑简化后是：

while (auto p = std::move(head)) {
    head = std::move(p->next);
}

每次循环中：

1. std::move(head)把head的所有权转移到p，head变为空；
2. head = std::move(p->next)执行移动赋值时，head当前是空的，所以reset步骤不会销毁任何资源，只会接管p->next的指针，最后（如果需要）移动p->next的deleter——整个过程完全符合标准，没有未定义行为。

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