第43章如何检测一个类型是否支持移动构造？

课程目录第43章如何检测一个类型是否支持移动构造？

43. 如何检测一个类型是否支持移动构造？

这个问题，说白了就是问：我怎么在编译期知道一个类能不能被移动？

我在做模板库的时候，经常需要根据类型特性走不同的分支。比如一个类型支持移动构造，我就走高效路径；不支持，我就退化成拷贝。你想想看，如果硬去移动一个不支持移动的类型，编译器会报错，或者更糟——它悄悄调用了拷贝构造，性能就没了。

嗯，C++标准库早就替我们想好了。核心工具就是 std::is_move_constructible 和 std::is_trivially_move_constructible。咱们一个一个说。

基础检测：std::is_move_constructible

这个 traits 类能告诉你：一个类型能否通过移动构造来创建。它的原理很简单——编译器检查是否存在 T(T&&) 或者 T(const T&)（当没有移动构造时，const T& 也能绑定到右值）。

#include <type_traits>
#include <iostream>
#include <string>
#include <vector>

struct NoMove {
    NoMove() = default;
    NoMove(const NoMove&) = default;
    NoMove(NoMove&&) = delete;  // 显式删除移动构造
};

struct HasMove {
    HasMove() = default;
    HasMove(HasMove&&) = default;
};

int main() {
    std::cout << std::boolalpha;
    
    // 基本类型
    std::cout << "int: " << std::is_move_constructible_v<int> << "\n";
    // 输出: true
    
    // 标准库类型
    std::cout << "std::string: " << std::is_move_constructible_v<std::string> << "\n";
    // 输出: true
    
    // 显式删除移动构造
    std::cout << "NoMove: " << std::is_move_constructible_v<NoMove> << "\n";
    // 输出: true —— 因为 const NoMove& 可以绑定右值
    
    // 真正有移动构造的
    std::cout << "HasMove: " << std::is_move_constructible_v<HasMove> << "\n";
    // 输出: true
}

⚠️ 注意陷阱：

std::is_move_constructible 检测的是「能否从右值构造」，而不是「是否有用户定义的移动构造」。如果一个类只有拷贝构造（参数为 const T&），它也能接受右值，所以这个 traits 返回 true。

我曾经在代码评审时看到有人用这个 traits 来判断「是否有高效的移动操作」，结果误判了。说白了，它只保证能编译，不保证性能。

更精细的检测：std::is_trivially_move_constructible

如果你想知道移动构造是不是「无操作」或者「可以像 memcpy 一样处理」，那就用这个。

struct TrivialMove {
    int x;
    double y;
    // 编译器生成的移动构造是 trivial 的
};

struct NonTrivialMove {
    std::string name;  // string 的移动构造不是 trivial 的
};

int main() {
    std::cout << std::boolalpha;
    
    std::cout << "TrivialMove: " 
              << std::is_trivially_move_constructible_v<TrivialMove> << "\n";
    // 输出: true
    
    std::cout << "NonTrivialMove: " 
              << std::is_trivially_move_constructible_v<NonTrivialMove> << "\n";
    // 输出: false
}

💡 实用技巧：

在写容器或者泛型算法时，我习惯这样组合使用：

if constexpr (std::is_trivially_move_constructible_v<T>) {
    // 直接 memcpy，极快
    std::memcpy(dst, src, count * sizeof(T));
} else if constexpr (std::is_move_constructible_v<T>) {
    // 调用移动构造
    for (size_t i = 0; i < count; ++i)
        new (&dst[i]) T(std::move(src[i]));
} else {
    // 退化为拷贝
    for (size_t i = 0; i < count; ++i)
        new (&dst[i]) T(src[i]);
}

检测是否「真正支持移动语义」

有时候我们需要区分：这个类型是「有移动构造」还是「有高效的移动构造」？我个人会写一个辅助 traits：

template <typename T>
struct has_efficient_move : std::bool_constant<
    std::is_move_constructible_v<T> &&
    !std::is_same_v<
        decltype(std::declval<T&>() = std::declval<const T&>()),
        decltype(std::declval<T&>() = std::declval<T&&>())
    >
> {};

// 或者更简单的版本：检查移动构造是否比拷贝构造更便宜
template <typename T>
constexpr bool is_nothrow_move_cheap_v = 
    std::is_nothrow_move_constructible_v<T> &&
    !std::is_trivially_copy_constructible_v<T>;

核心结论：

std::is_move_constructible_v<T> —— 能否从右值构造（包括拷贝构造兜底）
std::is_trivially_move_constructible_v<T> —— 移动构造是否 trivial（可 memcpy）
std::is_nothrow_move_constructible_v<T> —— 移动构造是否不抛异常（强异常安全保证时需要）

知识体系图

下面这张图帮你理清这几个 traits 的关系和适用场景：

实际项目中的避坑指南

我曾经在写一个内存池分配器时踩过坑。当时我用 std::is_move_constructible 来判断是否可以用移动语义来重排元素，结果发现对于只定义了拷贝构造的类，它也返回 true。嗯，这就导致我走了移动分支，但实际上调用的还是拷贝构造，性能没提升。

后来我改成这样：

// 真正检测「是否有用户定义的移动构造」
template <typename T>
struct has_user_move_ctor : std::bool_constant<
    std::is_move_constructible_v<T> &&
    !std::is_copy_constructible_v<T>  // 如果拷贝不可用，移动一定存在
> {};

// 或者更精确的版本（需要 C++20）
template <typename T>
concept MovableEfficiently = requires(T t) {
    T(std::move(t));  // 必须能匹配到 T&& 构造
    requires !std::is_same_v<
        decltype(T(std::declval<T&&>())),
        decltype(T(std::declval<const T&>()))
    >;
};

📌 我的建议：

日常开发中，你只需要记住三个层次：

能不能编译通过 → is_move_constructible
是不是 trivial → is_trivially_move_constructible
会不会抛异常 → is_nothrow_move_constructible

这三个 traits 组合使用，基本能覆盖所有场景。我个人习惯在写容器时，优先检查 nothrow，再检查 trivial，最后 fallback 到普通移动。

好了，检测移动构造这件事，说白了就是用好标准库的 type traits。你只要记住：is_move_constructible 是「能不能」，is_trivially_move_constructible 是「快不快」，is_nothrow_move_constructible 是「稳不稳」。三个维度一组合，任何类型都能拿捏得死死的。