C++ move函数内部原理及自定义move2的正确性与生产可用性分析

你实现的move2仅能覆盖极窄的测试场景，本质存在多处缺陷，完全不能用于生产环境。 #

首先说为什么你的测试用例能得到和标准std::move一致的输出 #

你测试时传入的是vector<int>左值，且vector本身实现了移动构造，你的C风格强转刚好生成了右值触发移动构造，所以内存分配次数看起来没问题。但这只是巧合，只要换个场景就会出问题。

和GCC标准库的std::move实现对比，你的move2存在以下致命问题 #

• 参数接收范围受限
  你的实现参数是T& input，只能接收左值参数，无法接收右值作为入参。标准实现用了万能引用_Tp&& __t，通过引用折叠规则可以同时兼容左值、右值入参。
• 返回值设计错误
  你的实现返回值是T，会额外产生一次临时对象的构造/析构开销，遇到没有实现移动构造的类型时会直接触发拷贝，完全失去移动语义的作用。标准实现返回的是std::remove_reference<_Tp>::type&&右值引用，没有额外开销，仅做类型转换。
• 类型转换不安全
  你用了C风格的(T&&)强转，转换规则不明确，容易出现未定义行为。标准实现用static_cast做显式的类型转换，符合C++的安全转换规范。
• 缺少必要的修饰符
  标准实现加了constexpr支持编译期调用，加了noexcept告诉编译器该函数不会抛出异常，编译器可以做更多性能优化（比如容器扩容时如果元素的移动构造是noexcept，就会优先用移动而非拷贝保证性能）。
• 没有处理引用折叠边界情况
  如果模板参数T本身是引用类型，你的实现的强转逻辑会直接出错。标准实现用std::remove_reference先剥离掉参数的所有引用修饰，再转成右值引用，适配所有参数类型的场景。

结论 #

你当前的实现仅能满足你写的窄测试用例，存在大量边界问题和性能问题，绝对不能在生产环境使用，直接用标准库的std::move即可。

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