条款31.避免默认捕获模式
2021/5/17 10:25:57
本文主要是介绍条款31.避免默认捕获模式,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
lambda表达式
lambda
表达式,是表达式的一种,它是源代码组成部分。
std::find_if(container.begin(), container.end(), [](int val){ return 0 < val && val < 10; });
- 闭包是
lambda
创建的运行期对象,根据不同的捕获模式,闭包会持有数据的副本或引用。在上面的例子中,闭包就是作为第三个实参在运行期传递给std::find_if
的对象。4 - 闭包类就是实例化闭包的类,每个
lambda
式都会触发编译器生成一个独一无二的闭包类。而闭包中的语句会变成它的闭包类成员函数的可执行指令。
lambda
式常用于创建闭包并仅将其用作传递给函数的实参。不过,一般而言,闭包可以复制,所以,对应于单独一个lambda
式的闭包类型可以有多个闭包。
避免默认捕获模式
C++11中有两种默认捕获模式:按引用或按值。按引用的默认捕获模式可能导致空悬引用,按值得默认捕获模式会忽悠你,好像可以对空悬引用免疫(其实并没有),还让你认为你的闭包是独立的。
按引用捕获会导致闭包含指向到局部变量的引用,或者指向到定义lambda
式的作用域内的形参的引用。一旦由lambda
所创建的闭包越过了该局部变量或形参的生命期,那么闭包内的引用就会空悬。例如,我们有一个元素为筛选函数的容器,其中每个筛选函数都接受一个int
,并返回一个bool
以表示传入的值是否满足筛选条件:
using FilterContainer = std::vector<std::function<bool(int)>>; //关于using FilterContainer filters; //元素为筛选函数的容器
我们可以像下面这样添加一个筛选5的倍数的函数:
filters.emplace_back( [](int value){ return value % 5 == 0; } );
但是我们可能需要在运行期计算出除数,而不是把硬编码的”5“写入lambda
式中,所以,添加筛选器的代码可能与下面的代码相似。
void addDivisorFilter() { auto calc1 = computeSomeValue1(); auto calc2 = computeSomeValue2(); auto divisor = computeDivisor(calc1, calc2); filters.emplace_back( //危险 [&](int value) { return value % divisor == 0; } //对divisor ); //的指向可能空悬 }
这段代码随时会出错。lambda
式是指向到局部变量divisor
的引用,但该变量在addDivisorFilter
返回时即不再存在。换言之,该变量的销毁就是紧接着filters.emplace_back
返回的那一刻。所以这就等于说,添加到筛选器的那个函数刚刚被添加完就消亡了。使用这个筛选器,从它刚被创建的那一刻,就会产生未定义行为。
就算不这样做,换做以显式方式按引用捕获divisor
,问题依旧。
filters.emplace_back( [&divisor](int value) { return value % divisor == 0; } //危险,对divisor的指向可能空悬 );
不过,通过显式捕获,确实较容易看出lambda
式的生存依赖于divisor
的生命期。而且,明白地写出名字divisor
还提醒了我们,再次确认了divisor
至少和该lambda
式的闭包具有一样长的生命期。比起[&]
所传达的这种不痛不痒的”要保证没有空悬“式的劝告,显式指明更让人印象深刻。
如果你知道闭包会被立即使用(例如,传递给STL算法)并且不会复制,那么在lambda
式中使用引用将不会有风险。
例如,我们的筛选器lambda
式仅用作C++11的std::all_of
的实参,后者的作用是返回某作用域内的元素是否都满足某条件的判断。
template<typename C> void workWithContainer(const C& container) { auto calc1 = computeSomeValue1(); auto calc2 = computeSomeValue2(); auto divisor = computeDivisor(calc1, calc2); using ContElemT = typename C::value_type; using std::begin; using std::end; if(std::all_of( //如果所有 begin(container), end(container), //容器中的元素值 [&](const ContElemT& value) //都是divisor { return value % divisor == 0; })) //的倍数 { ... } else { ... } }
不错,这样使用的确安全,但是这样的安全可谓朝不保夕。如果发现该lambda
式在其他语境中有用(例如,加入到filters
容器中成为一个函数元素),然后被复制并黏贴到其他闭包比divisor
生命期更长的语境中的话,你就要被拖回空悬的困境了。
从长远观点来看,显式地列出lambda
式所依赖的局部变量或形参是更好的软件工程实践。
顺便说下,C++14提供了在lambda
式的形参声明中使用auto
的能力,这意味着上面的代码在C++14中可以简化,ContElemT
的声明可以删去,而if
条件可以更改如下。
if(std::all_of(begin(container), end(container), [&](const auto& value) { return value % divisor == 0; }))
解决这个问题的一种方法就是对divisor
采用按值得默认捕获模式。即,我们这样向容器添加lambda
式。
filters.emplace_back( [=](int value) { return value % divisor == 0; } );
对于本例来说,这样做已经足够了。但是,总的来说,按值的默认捕获并非你想象中能够避免空悬的灵丹妙药。问题在于,按值捕获了一个指针以后,在lambda
式创建的闭包中持有的是这个指针的副本,但你并没办法阻止lambda
式之外的代码去针对该指针实施delete
操作所导致的指针副本空悬。
假设Widget
类可以实施的一个操作是向筛选器容器中添加条目:
class Widget{ public: ... //构造函数等 void addFilter() const; //向filters添加一个条目 private: int divisor; //用于Widget的filters元素 };
Widget::addFilter
可能作如下定义
void Widget::addFilter() const { filters.emplace_back( [=](int value){ return value % divisor == 0; } ); }
这段代码错了,错得彻底。
捕获只能针对于在创建lambda
式的作用域内可见的非静态局部变量(包括形参)。divisor
并非局部变量,而是Widget
类的成员变量,它根本不能被捕获。
这么一来,如果默认捕获模式被消除,代码就不会通过编译:
void Widget::addFilter() const { filters.emplace_back( [](int value){ return value % divisor == 0; } ); }
而且,如果试图显式捕获divisor
(无论是按值还是按引用),这个捕获语句都不能通过编译,因为divisor
既不是局部变量,也不是形参;
void Widget::addFilter() const { filters.emplace_back( [divisor](int value){ return value % divisor == 0; } ); }
为什么这两个语句会编译失败,关键在于一个裸指针的隐式应用,这就是this
。每一个非静态成员函数都持有一个this
指针,然后每当提及该类的成员变量时都会用到这个指针。例如,在Widget
的任何成员函数中,编译器内部都会把divisor
替换成this->divisor
。在Widget::addFilter
的按值默认捕获版本中。
void Widget::addFilter() const { filters.emplace_back( [=](int values){ return value% divisor == 0; } ); }
被捕获的实际上是Widget
的this
指针,而不是divisor
。从编译器的视角来看,上述代码相当于
void Widget::addFilter() const { auto currentObjectPtr = this; filters.emplace_back( [currentObjectPtr](int value) { return value % currentObject->divisor == 0; } ); }
理解了这一点,也就相当于理解了lambda
闭包的存活于它含有其this
指针副本的Widget
对象的生命期是绑在一起的。特别的,考虑下面的代码,它掌握了第4章精髓,仅使用了智能指针。
using FilterContainer = std::vector<std::function<bool(int)>>; FilterContainer filters; void doSomeWork() { auto pw = std::make_unique<Widget>(); pw->addFilter(); //添加使用了Widget::divisor的筛选函数 ... //Widget被销毁,filters现在持有空悬指针 }
当调用doSomeWork
时创建了一个筛选函数,它依赖于std::make_unique
创建的Widget
对象,即,一个含有指向Widget
的指针(Widget
的this
指针的副本)的筛选函数。该函数被添加到filters
中,不过当doSomeWork
执行结束之后,Widget
对象即被管理着它的生命周期的std::unique_ptr
销毁,从那一刻起,filter
中就含有了一个带有空悬指针的元素。
这一特定问题可以通过将你想捕获的成员变量拷贝到局部变量中,然后捕获该局部副本加以解决。
void Widget::addFilter() const { auto divisorCopy = divisor; //拷贝成员变量 filters.emplace_back( //捕获副本 [divisorCopy](int value){ return value % divisorCopy == 0; } //使用副本 ); }
实话实说,如果拟采用这种方法,那么按值得默认捕获也能够运行
void Widget::addFilter() const { auto divisorCopy = divisor; //拷贝成员变量 filters.emplace_back( //捕获副本 [=](int value){ return value % divisorCopy == 0; } //使用副本 ); }
在C++14中,捕获成员变量的一种更好的办法是使用广义lambda
捕获。
void Widget::addFilter() const { filters.emplace_back( [divisor = divisor](int value){ return value % divisor == 0; } //将divisor拷贝入闭包 ); }
对于广义lambda
捕获而言,没有按默认捕获模式一说。但是就算在C++14中,本条款的建议仍然成立。
使用默认值捕获模式的另外一个缺点是,在于它们似乎表明相关的闭包是独立的并且不受外部数据变化的影响。一般来说,这是不对的。因为lambda
式不仅依赖于局部变量和参数,它们还会依赖静态存储器对象。这样的对象定义在全局或名字空间作用域中,又或在类中,在函数中,在文件中以static
饰词声明。这样的对象可以在lambda
对象中使用,但是它们不能被捕获,但如果使用了按默认值捕获模式,这些对象就会给人错觉,认为它们可以被捕获。
void addDivisorFilter() { static auto calc1 = computeSomeValue1(); //现在以static饰词声明 static auto calc2 = computeSomeValue2(); //现在以static饰词声明 static auto divisor = computeDivisor(calc1, calc2); //现在以static饰词声明 filters.emplace_back( [=](int value) { return value % divisor == 0; } //未捕获任何东西 ); ++divisor; //意外修改了divisor }
一目十行的读者在看到代码中有着[=]
后,就会想当然地认为,lambda
是独立的。但是lambda
并非独立,因为它没有使用任何的非静态局部变量和形参,所以它没能捕获任何东西。然而lambda
的代码引用了静态变量divisor
,任何lambda
被添加到filters
之后,divisor
都会递增。通过这个函数,会把许多lambda
都添加到filters
中,但每一个lambda
的行为都不一样。
从实际效果来看,这个lambda
式实现的效果是按引用捕获divisor
,和按值默认捕获所暗示的含义有着直接的矛盾。
要点速记
- 按引用的默认捕获会导致空悬指针问题。
- 按值的默认捕获极易受到空悬指针的影响(尤其是
this
),并会误导人们认为lambda
是独立的。
这篇关于条款31.避免默认捕获模式的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-12-29设计Element UI表单组件居然如此简单!
- 2024-12-28一步到位:购买适合 SEO 的域名全攻略
- 2024-12-27OpenFeign服务间调用学习入门
- 2024-12-27OpenFeign服务间调用学习入门
- 2024-12-27OpenFeign学习入门:轻松掌握微服务通信
- 2024-12-27OpenFeign学习入门:轻松掌握微服务间的HTTP请求
- 2024-12-27JDK17新特性学习入门:简洁教程带你轻松上手
- 2024-12-27JMeter传递token学习入门教程
- 2024-12-27JMeter压测学习入门指南
- 2024-12-27JWT单点登录学习入门指南