在C++17中，标准引入了保证的拷贝消除（强制拷贝消除），这从根本上改变了如何物化prvalue（纯右值）。当类类型的prvalue初始化同类型对象时，比如通过值从函数返回或将临时值传递给函数时，对象直接在目的存储中构造。因此，拷贝构造函数或移动构造函数不会被调用，并且重要的是，它们的可访问性（公有与私有）或仅仅存在（假设类是完整的且可析构）对操作的有效性没有要求。这与早期标准形成了鲜明的对比，早期版本中的拷贝消除只是一个可选优化，仍然要求访问可及且存在的构造函数以便编译。
struct Immovable { Immovable() = default; Immovable(const Immovable&) = delete; Immovable(Immovable&&) = delete; }; Immovable factory() { return Immovable{}; // 在C++17中是可以的：没有调用移动/拷贝 } void consume(Immovable x); // 参数直接从prvalue初始化
我们团队正在构建一个内核模式驱动程序，其中包装硬件上下文的资源句柄由于注册内核地址无法复制或重新定位在内存中。我们需要一个工厂函数通过值生成这些句柄以进行RAII管理，但这些句柄明确删除了拷贝和移动构造函数以防止意外使内核映射失效。在C++17之前，这种设计与通过值返回不兼容，因为即使在NRVO下，编译器在概念上也要求移动构造函数可访问，导致编译错误。
解决方案1：通过 std::unique_ptr 的堆分配
我们考虑将句柄包装在 std::unique_ptr 中，允许指针移动的同时将底层对象保持固定。这种方法提供了安全性，并且在C++14中是可行的。
优点: 标准内存管理，防止内存泄漏，广泛支持旧代码库。
缺点: 引入动态分配开销和指针间接寻址，在需要确定性低延迟的内核上下文中是不可接受的；也会导致CPU缓存碎片，并且需要处理分配失败的异常情况。
解决方案2：输出参数初始化
将对调用者分配的对象的引用传入工厂以在原地初始化。
优点: 无论C++标准版本如何，均无复制保证；没有堆分配；与不可移动类型兼容。
缺点: 破坏了流畅的API风格（auto h = create(); 变为 Handle h; create(h);）；增加了使用前初始化的风险，并且与标准算法和基于范围的 for 循环组合不佳。
解决方案3：利用C++17保证的拷贝消除
我们重构了工厂以通过值返回不可移动类型，依赖强制消除将prvalue直接构造到调用者的存储中。
优点: 消除了堆使用；保持值语义；在编译时加强零成本抽象；移动/拷贝构造函数不需要存在或可访问。
缺点: 严格适用于纯右值（不能返回已命名的变量）；要求支持C++17的编译器；在构造期间必须理解细微的异常处理差异。
我们选择了解决方案3，因为工厂生成的新临时变量是纯prvalue，完美匹配保证消除场景。这使得句柄保持严格不可移动，同时保持符合“自动”声明的符合人体工程学的值语义。
驱动程序以微秒级别的初始化速度处理数千个并发连接。汇编检查确认句柄直接在调用者的栈帧中构造，而没有任何重新定位或复制代码。类型系统通过构造严格强制实施资源安全，我们彻底消除了热路径中的堆争用。
保证的拷贝消除是否适用于函数内部的命名返回值（左值），还是严格限于prvalues？
保证的拷贝消除专门适用于prvalues（纯右值），例如在返回语句中创建的没有名称的临时对象。命名返回值优化（NRVO）仍然是一个可选的编译器优化；虽然广泛实现，但并未提供关于构造函数可访问性或副作用的相同保证。如果候选人试图返回一个命名的局部变量并假设它会触发保证的消除，即使移动构造函数被删除，程序将是无效的，因为命名变量是lvalues，并且要求移动/拷贝操作，除非编译器应用可选的NRVO，这并不是强制的。
在保证拷贝消除规则下，是否可以从函数中按值返回显式删除的拷贝和移动构造函数的类？
可以。在C++17中，如果返回的表达是prvalue（例如，return MyClass{};），则在初始化时永远不会考虑拷贝和移动构造函数。因为对象直接在调用者的存储中构造，已删除的构造函数不会被使用并且不会导致编译错误。然而，尝试返回此类类型的命名变量将失败，因为该操作概念上需要将lvalue移动到返回槽，这将调用已删除的移动构造函数并导致程序无效。
保证的拷贝消除如何与异常安全性交互，具体而言，在栈展开过程中prvalue临时的生命周期如何？
在保证的拷贝消除下，在目标对象生命周期开始之前不会创建单独的临时对象。prvalue直接在其最终位置上物化。因此，如果在prvalue构造期间发生异常，栈展开机制不会遇到需要销毁的单独临时；相反，它会看到部分构造的目标对象。这意味着从调用者的角度来看，该对象要么完全构造，要么根本不存在，从而简化了异常安全保证，确保在目标对象的生命周期正式开始之前，不会因在异常处理过程中被放弃的临时对象而发生双重销毁或资源泄漏。