显式调用析构与构造函数重建对象是否为不良编程实践？

先看你给出的代码示例：

#include <string>
#include <map>
int main() {
 using Pair = std::pair<const std::string, int>;
 Pair p1("abc", 5);
 Pair p2;
 // 显然此代码无法编译，因为pair的第一个元素是const。编译器错误为：
 // Object of type 'std::__1::pair<const std::__1::basic_string<char>, int>' cannot be assigned because its copy assignment operator is implicitly deleted.
 //p2 = std::move(p1);
 // 但存在一种变通方案
 p2.~Pair();
 new (&p2) Pair(std::move(p1));
 return 0;
}

这种“手动销毁对象再用placement new原地重建”的写法，虽然能绕过赋值运算符被删除的限制，但绝对是需要尽量避免的不良实践，主要有这些弊端：

• 可读性与维护性灾难：这完全违背了C++开发者的常规认知，任何接手这段代码的人都会疑惑“为什么不直接用正常的构造/赋值？”。这种写法没有语义上的清晰性，相当于用底层内存操作代替了高层的对象语义，会让代码变得晦涩难懂，后续维护时很容易出错。

• 异常安全隐患：如果new (&p2) Pair(std::move(p1))这一步抛出异常（比如std::string的移动构造在某些极端场景下可能抛出，或者如果Pair的构造逻辑有其他抛异常的情况），那么p2的状态会变成“已析构但未成功重建”。此时这块内存处于无效状态，后续任何对p2的访问都是未定义行为，甚至程序退出时的自动析构都会导致双重销毁。

• 未定义行为的潜在风险：

  • 手动调用析构函数后，对象的生命周期已经结束，虽然你用placement new重新构造了对象，但如果原类型有一些依赖于对象生命周期的内部机制（比如某些类会注册自己到全局列表、使用内存池分配子对象等），手动析构可能会破坏这些机制，导致后续操作出问题。
  • 另外，如果后续代码不小心在p2重建前访问它，或者忘记重建直接释放内存，都会触发严重的未定义行为。

• 有更优雅、安全的替代方案：你完全没必要用这种hack写法，比如：

  • 如果对象还没初始化，直接用移动构造创建新对象：Pair p2(std::move(p1));
  • 如果是已经存在的对象（比如类成员），可以用std::optional来包裹，通过重置实现“赋值”：

    std::optional<Pair> p2 = Pair{};
    p2 = std::move(p1);
    

  • 要是涉及到容器中的const键值对（比如std::map的元素），正确的做法是先删除旧元素，再插入新的移动构造元素，而不是试图修改已有的元素。

• 阻碍编译器优化：正常的赋值或构造操作编译器会做大量优化（比如返回值优化、移动语义优化等），但这种手动内存操作会让编译器无法识别你的意图，无法进行常规优化，反而可能生成效率更低的代码。

总的来说，这种写法是典型的“为了绕过语法限制而牺牲代码安全性、可读性”的操作，完全不符合现代C++的编程理念，能不用就绝对不要用。

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