MSVC编译C++23 Move包装器代码时触发已删除析构函数调用的问题：编译器合规性与兼容方案咨询

问题背景与现象 #

你这段代码的核心是尝试用自定义Move包装器封装右值引用语义，替代显式的std::move，但在MSVC v19.latest上编译失败——它会莫名尝试调用NonDestructible的已删除析构函数，而GCC 14.2和Clang 19.1都能正常编译。出错的行是*t2 = Move(*t1);，MSVC的行为完全偏离了预期路径。

差异根源分析 #

根据你后续的调试结论，问题出在MSVC的重载决议与转换运算符匹配逻辑上：

• GCC和Clang会正确匹配Move<T>的operator T&& () const noexcept转换运算符，直接生成NonDestructible&&右值引用，触发移动赋值运算符，全程不会创建临时对象，自然也不会涉及析构函数调用。
• 但MSVC似乎完全忽略了这个右值转换运算符，反而尝试走const T&的转换路径——这会触发临时NonDestructible对象的创建逻辑，而临时对象在语句结束时必须销毁，直接撞上~NonDestructible() = delete的限制，导致编译报错。

合规性判定：谁对谁错？ #

从C++标准的角度来看：

1. 当我们需要为移动赋值运算符（operator=(T&&)）传参时，编译器应优先选择能生成右值引用的转换运算符，而非左值引用。
2. 你的static_assert(std::is_move_assignable_v<NonDestructible>)已通过，说明类型确实满足移动可赋值要求，MSVC的行为违反了重载决议的优先级规则与转换匹配逻辑。

结论：GCC和Clang的行为符合标准，MSVC存在编译器bug。

跨编译器兼容修复方案 #

针对MSVC的这个bug，你可以通过以下几种方式绕开，让代码在三大编译器上保持一致：

方案1：显式触发右值转换 #

不要依赖隐式转换，手动调用转换运算符，或给Move包装器新增显式获取方法：

template<class T>
struct Move {
    T&& value;
    Move(T& what) : value {std::move(what)} {}
    operator T&& () const noexcept { return std::forward<T>(value); }
    // 新增显式获取右值的方法
    T&& get() const noexcept { return std::forward<T>(value); }
};

// 调用时显式调用get()
*t2 = Move(*t1).get();

这种方式直接跳过MSVC的隐式转换bug，强制生成正确的右值引用。

方案2：修改Move包装器内部实现 #

将原来的T&& value成员改为指针，避免MSVC对引用成员的特殊处理逻辑：

template<class T>
struct Move {
    T* ptr;
    Move(T& what) : ptr(&what) {}
    operator T&& () const noexcept { return std::move(*ptr); }
};

指针语义更清晰，MSVC不会误判转换路径。

方案3：显式删除左值引用转换路径 #

直接阻断MSVC可能走的错误路径，显式删除const T&的转换运算符：

template<class T>
struct Move {
    T&& value;
    Move(T& what) : value {std::move(what)} {}
    operator T&& () const noexcept { return std::forward<T>(value); }
    // 显式删除左值引用转换，避免MSVC误匹配
    operator const T& () const = delete;
};

这样MSVC只能选择正确的右值转换运算符，不会再触发临时对象创建。

方案4：用显式static_cast替代Move包装器 #

如果你的Move包装器只是为了简化std::move写法，也可以直接用static_cast强制生成右值引用，完全绕开MSVC的bug：

*t2 = static_cast<NonDestructible&&>(*t1);

总结 #

MSVC的行为不符合C++标准，属于编译器实现bug；通过上述任意一种方案，你都可以绕开问题，让代码在三大主流编译器上保持一致行为。

内容来源于stack exchange