c++oding="utf-8" ?>
std::vector扩容时是否启用memmove优化取决于std::is_nothrow_move_constructible_v：仅当该trait为true且类型满足平凡析构等条件时，libstdc++等实现才跳过逐个移动构造而直接位拷贝。
如果 std::vector 扩容时底层想用 memmove 而不是逐个调用移动构造函数，std::is_nothrow_move_constructible 就是那个决定性的开关——它不只是一纸编译期断言，而是直接影响内存布局策略和性能拐点的关键 trait。
std::vector::reserve 和 reallocate 时怎么用到它
当 std::vector 需要扩容（比如 push_back 触发重分配），标准库会检查元素类型是否满足 std::is_nothrow_move_constructible_v<t></t>。若为 true，且该类型还满足 std::is_trivially_destructible_v<t></t>，部分实现（如 libstdc++、libc++）会启用“位拷贝优化”：直接 memmove 原内存块到新地址，跳过所有移动构造与析构调用。
- 没这个 trait，哪怕移动构造函数实际不抛异常，也会被当作可能抛出处理，强制逐个移动 + 析构
- 对 POD 类型或简单结构体，这能带来 2–5 倍的扩容吞吐提升（实测百万级
intvs 自定义 move 构造但未标noexcept的 struct） - 注意：仅当移动构造 + 移动赋值 + 析构三者都
noexcept，且类型非 final 时，优化才可能生效（某些 STL 实现有额外约束）
为什么加了 noexcept 还不被识别
常见误判不是因为没写 noexcept，而是 trait 检查的是“移动构造函数是否被声明为 noexcept”，而非“是否真的不抛”。即使函数体里什么都没写，只要声明缺失，std::is_nothrow_move_constructible 就返回 false。
- 显式默认构造器不会自动继承
noexcept：写T(T&&) = default;不够，得写T(T&&) noexcept = default; - 成员有非 nothrow 移动构造的子对象？整个类的 trait 直接为
false，哪怕你手动写了空的noexcept构造函数 - 基类未声明
noexcept移动构造？派生类即使写了，也会因基类拖累而失败 - 用
static_assert快速验证：static_assert(std::is_nothrow_move_constructible_v<mytype>);</mytype>
自定义类型必须显式控制的三个点
你无法依赖编译器“猜出”你的移动构造安全——尤其涉及资源管理时，必须主动干预。
-
移动构造函数声明必须带 <code>noexcept，不能只靠函数体空或无 throw； - 所有成员变量（含基类、组合对象）的移动构造也需满足
noexcept，否则 trait 短路失效； - 若类型内部有
std::mutex、std::thread等不可移动或移动可能抛异常的成员，std::is_nothrow_move_constructible必为false，此时应考虑禁用移动（删除移动操作）或改用指针托管，避免误信可优化
真正卡住 vector 扩容性能的，往往不是算法逻辑，而是某个被忽略的 noexcept 缺失——它让编译器不敢做位拷贝，又让你的 profile 报表里看不到明显热点。检查方式很简单：std::is_nothrow_move_constructible_v<t></t> 在编译期就能告诉你答案，别等压测时再翻源码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
