洗钱的目的是什么？

P0137 介绍了函数模板 std::launder，并在关于联合、生存期和指针的章节中对标准进行了许多许多修改。

这篇论文正在解决的问题是什么？我需要注意的语言变化是什么？我们在做什么？

45370 次浏览
小开
最佳答案

std::launder的名字很贴切，不过前提是你知道它的用途。它执行内存洗钱。

请看本文中的例子:

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


U u = \{\{ 1 }};

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

因为n是一个const变量，编译器可以自由地假设u.x.n应该是总是为1。

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

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

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

告诉我…u.x.n将返回什么?

显然答案是2。但这是错误的，因为编译器被允许假设一个真正的const变量(不仅仅是const&，而是一个对象变量宣布 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++标准允许编译器假设以某种方式获得的const限定的或引用的非静态数据成员的值是不可变的，即使它的包含对象是非const的，并且可以通过放置new来重用。

在c++ 17/P0137R1中，std::launder作为禁用前面提到的(错误)优化(CWG 1776)的功能被引入，这是std::optional所需要的。正如P0532R0中所讨论的，std::vector和std::deque的可移植实现也可能需要std::launder，即使它们是c++ 98组件。

幸运的是，这样的(错误)优化被RU007(包含在P1971R0和c++ 20中)禁止。AFAIK没有编译器执行这个(错误)优化。

去虚拟化障碍

虚拟表指针(vptr)在其包含的多态对象的生命周期内可以被视为常量，这是去虚拟化所需要的。鉴于vptr不是非静态数据成员，在某些情况下，编译器仍然允许基于vptr没有改变的假设(即，要么对象仍在其生命周期内，要么它被相同动态类型的新对象重用)执行去虚拟化。

对于一些用不同动态类型的新对象替换多态对象的不寻常用途(如在这里所示)，需要std::launder作为去虚拟化的屏障。

IIUC Clang使用这些语义(LLVM-D40218)实现了std::launder (__builtin_launder)。

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

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

因此，P0137R1直接使用未定义的__abc0d数组对__abc0d指针的解引用，即使该数组为另一个正确类型的对象提供了存储空间。然后需要std::launder来访问嵌套对象。

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

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

IIUC std::launder和基于类型的别名分析/严格别名是不相关的。std::launder要求正确类型的活对象位于所提供的地址。

然而，它们似乎意外地在Clang (LLVM-D47607)中被关联起来。


提交答案