std：：launder的目的是什么？

std::launder这个名字很贴切，但前提是你知道它的用途。它执行内存清洗。

请看论文中的例子：

struct X { const int n; };
union U { X x; float f; };
...

U u = {{ 1 }};

该语句执行聚合初始化，初始化 的第一个成员 with .U{1}

因为是一个变量，所以编译器可以自由地假设它始终为 1。nconstu.x.n

那么，如果我们这样做会发生什么：

X *p = new (&u.x) X {2};

因为这是微不足道的，我们不需要在创建新对象之前销毁旧对象，所以这是完全合法的代码。新对象的成员为 2。Xn

所以告诉我......什么会回来？u.x.n

显而易见的答案是 2。但这是错误的，因为编译器被允许假设一个真正的变量（不仅仅是一个，而是一个声明的对象变量）永远不会改变。但我们只是改变了它。constconst&const

[basic.life]/8 阐明了可以通过变量/指针/对旧对象的引用访问新创建的对象的情况。拥有会员是取消资格的因素之一。const

所以。。。我们怎样才能正确地谈论？u.x.n

我们必须洗白我们的记忆：

assert(*std::launder(&u.x.n) == 2); //Will be true.

洗钱用于防止人们追踪您的资金来源。内存清洗用于防止编译器跟踪从何处获取对象，从而强制编译器避免任何可能不再适用的优化。

另一个不合格因素是是否更改了对象的类型。 也可以在这里提供帮助：std::launder

alignas(int) char data[sizeof(int)];
new(&data) int;
int *p = std::launder(reinterpret_cast<int*>(&data));

[basic.life]/8 告诉我们，如果在旧对象的存储中分配一个新对象，则无法通过指向旧对象的指针访问新对象。 允许我们回避这一点。launder

std::launder用词不当。此函数执行与洗钱相反的操作：它弄脏指向的内存，以消除编译器可能对指向值的任何期望。它排除了基于此类预期的任何编译器优化。

因此，在@NicolBolas的回答中，编译器可能假设某些内存具有一些常量值;或未初始化。你是在告诉编译器：“那个地方（现在）被弄脏了，不要做出这样的假设”。

如果你想知道为什么编译器一开始就总是坚持它幼稚的期望，并且需要你明显地为它弄脏东西 - 你可能想阅读这个讨论：

为什么要引入“std：：launder”而不是让编译器来处理它？

...这让我想到了这种含义。std::launder

我认为有两个目的。std::launder

1. 不断折叠/传播的障碍，包括去虚拟化。
2. 基于细粒度对象结构的别名分析的障碍。

用于过度激进的恒定折叠/传播的屏障（已放弃）

从历史上看，C++ 标准允许编译器假定以某些方式获得的常量限定或引用非静态数据成员的值是不可变的，即使其包含对象是非常量并且可以通过放置 new 来重用。

在 C++17/P0137R1 中，作为禁用上述（错误）优化 （CWG 1776） 的功能引入，这是 .正如P0532R0中所讨论的，可移植的实现 和 可能还需要 ，即使它们是 C++98 组件。std::launderstd::optionalstd::vectorstd::dequestd::launder

幸运的是，RU007（包含在 P1971R0 和 C++20 中）禁止这种（错误）优化。AFAIK 没有编译器执行此（错误）优化。

去虚拟化的障碍

虚拟表指针 （vptr） 在其包含多态对象的生存期内可以被视为常量，这是去虚拟化所必需的。鉴于 vptr 不是非静态数据成员，在某些情况下，编译器仍允许基于未更改 vptr 的假设（即对象仍处于其生命周期中，或者被相同动态类型的新对象重用）执行去虚拟化。

对于一些不寻常的用途，需要用不同动态类型的新对象替换多态对象（如下所示），作为去虚拟化的障碍。std::launder

IIUC Clang 使用这些语义实现了 （） （LLVM-D40218）。std::launder__builtin_launder

基于对象结构的别名分析的屏障

P0137R1还通过引入指针互换性来更改C++对象模型。IIUC 的这种变化使 N4303 中提出的一些“基于对象结构的别名分析”成为可能。

因此，P0137R1直接使用从未定义的数组中取消引用 'd 指针，即使该数组正在为另一个正确类型的对象提供存储。然后需要访问嵌套对象。reinterpret_castunsigned char [N]std::launder

这种别名分析似乎过于激进，可能会破坏许多有用的代码库。AFAIK 它目前尚未由任何编译器实现。

与基于类型的别名分析/严格别名的关系

IIUC 和基于类型的别名分析/严格别名无关。 要求正确类型的活体位于提供的地址。std::launderstd::launder

然而，它们似乎在 Clang （LLVM-D47607） 中意外地相关。