为什么不可变lambda中的字段在捕获常量值或常量引用时使用“const”？

Question

如问题所示，值可变的lambda捕获不适用于常量

但是为什么对不可变的lambda也这样做呢？在不可变lambda中，运算符（）声明为const，因此它无论如何都不能修改捕获的值。

当我们移动lambda时，这种情况的坏后果就会发生，例如，当我们将lambda包装在一个std::function中时。

请参见以下两个示例：

#include <cstdio>
#include <functional>

std::function<void()> f1, f2;

struct Test {
    Test() {puts("Construct");}
    Test(const Test& o) {puts("Copy");}
    Test(Test&& o) {puts("Move");}
    ~Test() {puts("Destruct");}
};

void set_f1(const Test& v) {
    f1 = [v] () {}; // field type in lambda object will be "const Test"
}

void set_f2(const Test& v) {
    f2 = [v = v] () {}; // field type in lambda object will be "Test"
}

int main() {
    Test t;
    puts("set_f1:");
    set_f1(t);
    puts("set_f2:");
    set_f2(t);
    puts("done");
}

我们得到以下编译器生成的lambda类：

class set_f1_lambda {
    const Test v;
public:
    void operator()() const {}
};

class set_f2_lambda {
    Test v;
public:
    void operator()() const {}
};

程序打印以下内容（使用gcc或clang）：

Construct
set_f1:
Copy
Copy
Copy
Destruct
Destruct
set_f2:
Copy
Move
Move
Destruct
Destruct
done
Destruct
Destruct
Destruct

在第一个示例中，set\u f1至少复制了三次v值。

在第二个示例set_f2中，唯一的副本是捕获值时（如预期的那样）。使用两个移动是libstdc中的一个实现细节。当按值传递函子给内部函数时，第一个移动发生在operator=的std:：function内部（为什么此函数签名不使用按引用传递？）。第二个移动发生在move构造最终的堆分配函子时。

但是，如果字段是常量，lambda functor对象的移动构造函数就不能对该字段使用移动构造函数（因为这样的构造函数在窃取常量变量的内容后无法“清除”该变量）。这就是为什么这些字段必须使用复制构造函数的原因。

所以对我来说，在不可变的lambdas中捕获值作为const似乎只有负面影响。我是错过了一些重要的东西，还是只是以这种方式标准化，使标准更加简单？

Answer 1

我是否遗漏了一些重要的东西，或者只是通过这种方式进行了标准化，以使标准更加简单？

最初的lambda提案，

• N2550： Lambda表达式和闭包：单形Lambdas的用词（修订版4）

区分捕获对象的类型和lambda闭包类型的相应数据成员的类型：

/6闭包对象的类型是一个具有唯一名称的类，称为F，被认为是在lambda表达式出现的地方定义的。

在lambda表达式出现的上下文中查找有效捕获集中的每个名称N，以确定其对象类型；对于引用，对象类型是引用引用的类型。对于有效捕获集中的每个元素，F都有一个私有的非静态数据成员，如下所示：

• 如果元素是this，那么数据成员有一些唯一的名称，称之为t，并且是this类型（[class.this]，9.3.2）
• 如果元素的形式为

在最初的措辞中，OP的示例不会导致const限定的数据成员v。我们还可以指出，我们认识到措辞

对于引用，对象类型是引用引用的类型

在lambdas的最终措辞（最新草案）的[expr.prim.lambda.capture]/10中（但直接说明数据成员的类型，而不是对象类型）：

如果实体是对对象的引用，则此类数据成员的类型为引用类型；如果实体是对函数的引用，则此类数据成员的类型为对引用函数类型的左值引用；否则，则此类数据成员的类型为相应捕获实体的类型。

发生的事是

• N2927:C 0x Lambdas的新措辞（第2版）

重新编写了N2550中的大部分措辞：

在2009年3月首脑会议期间，核心工作组（CWG）提出并审查了大量与C/D相关的问题。在为这些问题中的大多数确定了明确的方向后，CWG得出结论，最好重写关于Lambdas的部分，以实现该方向。本文介绍了这种重写。

特别是在这个问题的背景下，解决CWG问题

• CWG 756。在闭包对象的成员上删除cv限定

[...] 考虑下面的例子：

void f() {
  int const N = 10;
  [=]() mutable { N = 30; }  // Okay: this->N has type int, not int const.
  N = 20;  // Error.
}

也就是说，作为闭包对象成员的N不是const，即使捕获的变量是const。这似乎很奇怪，因为捕获基本上是一种捕获本地环境的方法，可以避免生命周期问题。更严重的是，类型的更改意味着应用于lambda表达式中捕获的变量的decltype、重载解析和模板参数推断的结果可能与包含lambda表达式的范围中的结果不同，这可能是一个微妙的bug源。

在这之后（从N2927开始）的措辞变成了我们最后看到的C 11

这种数据部件的类型是如果实体不是对对象的引用则捕获的相应实体的类型，或者以其他方式引用的类型。

如果我敢猜测，CWG 756的决议还意味着保留参考类型实体价值捕获的cv限定符，这可能是一种疏忽。