effective_modern_c++
  • 前言
  • 1 类型推导
    • 条款1 理解模板类型推导
    • 条款2 理解auto类型推导
    • 条款3 理解decltype
    • 条款4 知道如何查看类型推导
  • 2 auto
    • 条款5 优先使用auto而非显式声明
    • 条款6 当auto推导出非预期类型时应当使用显式的类型初始化
  • 3 使用高级cpp特性
    • 条款7 创造对象时区分()和{}
    • 条款8 优先使用nullptr而不是0或者NULL
    • 条款9 优先使用声明别名而不是typedef
    • 条款10 优先使用作用域限制的enum而不是无作用域的enum
    • 条款11 优先使用delete关键字删除函数而不是private却又不实现的函数
    • 条款12 使用override关键字声明覆盖的函数
    • 条款13 优先使用const_iterator而不是iterator
    • 条款14 如果函数不抛出异常请使用noexcept
    • 条款15 尽可能使用constexpr
    • 条款16 让const成员函数线程安全
    • 条款17 理解特殊成员函数的生成
  • 4 智能指针
    • 条款18 对于独占资源使用std::unique_ptr
    • 条款19 对于共享资源使用std::shared_ptr
    • 条款20 当std::shared_ptr可能悬空时使用std::weak_ptr
    • 条款21 优先考虑使用std::make_unique和std::make_shared,而非直接使用new
    • 条款22 当使用Pimpl惯用法,请在实现文件中定义特殊成员函数
  • 5 右值引用和完美转发
    • 条款23 理解std::move和std::forward
    • 条款24 区分通用引用和右值引用
    • 条款25 对右值引用使用std::move,对通用引用使用std::forward
    • 条款26 避免在通用引用上重载
    • 条款27 熟悉通用引用重载的替代方法
    • 条款28 理解引用折叠
    • 条款29 假定移动操作不存在,成本高,未被使用
    • 条款30 熟悉完美转发失败的情况
  • 6 lambda表达式
    • 条款31 避免使用默认捕获模式
    • 条款32 使用初始化捕获来移动对象到闭包中
    • 条款33 对auto&&形参使用decltype以便std::forward它们
    • 条款34 考虑lambda而非std::bind
  • 7 并发api
    • 条款35 优先考虑基于任务的编程而非基于线程的编程
    • 条款36 如果有异步的必要请指定std::async::launch
    • 条款37 使std::thread在所有路径最后都不可结合
    • 条款38 关注不同线程句柄的析构行为
    • 条款39 对于一次性事件通信考虑使用void的futures
    • 条款40 对于并发使用std::atomic,对于特殊内存使用volatile
  • 8 些许调整
    • 条款41 对于移动成本低且总是被拷贝的可拷贝形参,考虑按值传递
    • 条款42 考虑使用置入代替插入
Powered by GitBook
On this page
  1. 6 lambda表达式

条款31 避免使用默认捕获模式

C++11中有两种默认的捕获模式:按引用捕获和按值捕获。但默认按引用捕获模式可能会带来悬空引用的问题,而默认按值捕获模式可能会诱骗你让你以为能解决悬空引用的问题(实际上并没有),还会让你以为你的闭包是独立的(事实上也不是独立的)。

这就是本条款的一个总结。如果你偏向技术,渴望了解更多内容,就让我们从按引用捕获的危害谈起吧。

按引用捕获会导致闭包中包含了对某个局部变量或者形参的引用,变量或形参只在定义lambda的作用域中可用。如果该lambda创建的闭包生命周期超过了局部变量或者形参的生命周期,那么闭包中的引用将会变成悬空引用。举个栗子,假如我们有元素是过滤函数(filtering function)的一个容器,该函数接受一个int,并返回一个bool,该bool的结果表示传入的值是否满足过滤条件:

using FilterContainer =
    std::vector<std::function<bool(int)>>;

FilterContainer filters;  // 过滤函数

我们可以添加一个过滤器,用来过滤掉5的倍数:

filters.emplace_back([](int value) {
    return value % 5 == 0;
});

然而我们可能需要的是能够在运行期计算除数(divisor),即不能将5硬编码到lambda中。因此添加的过滤器逻辑将会是如下这样:

void addDivisorFilter() {
    auto calc1 = computeSomeValue1();
    auto calc2 = computeSomeValue2();

    auto divisor = computeDivisor(calc1, calc2);

    filters.emplace_back([&](int value) {  // 危险!对divisor的引用将会悬空!
        return value % divisor == 0;
    });
}

这个代码实现是一个定时炸弹。lambda对局部变量divisor进行了引用,但该变量的生命周期会在addDivisorFilter返回时结束,刚好就是在语句filters.emplace_back返回之后。因此添加到filters的函数添加完,该函数就死亡了。使用这个过滤器会导致未定义行为,这是由它被创建那一刻起就决定了的。

现在,同样的问题也会出现在divisor的显式按引用捕获。

filters.emplace_back([&divisor](int value) {  // 危险!对divisor的引用将会悬空!
    return value % divisor == 0;
});

但通过显式的捕获,能更容易看到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) {  // 如果容器内所有值都为除数的倍数
            return value % divisor == 0;
        }
    )) {
        ...  // 它们...
    } else {
        ...  // 至少有一个不是的话...
    }
}

的确如此,这是安全的做法,但这种安全是不确定的。如果发现lambda在其它上下文中很有用(例如作为一个函数被添加在filters容器中),然后拷贝粘贴到一个divisor变量已经死亡,但闭包生命周期还没结束的上下文中,你又回到了悬空的使用上了。同时,在该捕获语句中,也没有特别提醒了你注意分析divisor的生命周期。

从长期来看,显式列出lambda依赖的局部变量和形参,是更加符合软件工程规范的做法。

额外提一下,C++14支持了在lambda中使用auto来声明变量,上面的代码在C++14中可以进一步简化,ContElemT的别名可以去掉,if条件可以修改为:

if (std::all_of(  // C++14
    begin(container), end(container), [&](const auto& value) {
        return value % divisor == 0;
    }
))

一个解决问题的方法是,divisor默认按值捕获进去,也就是说可以按照以下方式来添加lambda到filters:

filters.emplace_back([=](int value) {  现在divisor不会悬空了
    return value % divisor == 0;
});

这足以满足本实例的要求,但在通常情况下,按值捕获并不能完全解决悬空引用的问题。这里的问题是如果你按值捕获的是一个指针,你将该指针拷贝到lambda对应的闭包里,但这样并不能避免lambda外delete这个指针的行为,从而导致你的副本指针变成悬空指针。

也许你要抗议说:“这不可能发生。看过了第4章,我对智能指针的使用非常热衷。只有那些失败的C++98的程序员才会用裸指针和delete语句。”这也许是正确的,但却是不相关的,因为事实上你的确会使用裸指针,也的确存在被你delete的可能性。只不过在现代的C++编程风格中,不容易在源代码中显露出来而已。

假设在一个Widget类,可以实现向过滤器的容器添加条目:

class Widget {
public:
    ...
    void addFilter() const;  // 向filters添加条目

private:
    int divisor;  // 在widget的过滤器中使用
};

这是Widget::addFilter的定义:

void Widget::addFilter() const {
    filters.emplace_back([=](int value) {
        return value % divisor == 0;
    });
}

这个做法看起来是安全的代码。lambda依赖于divisor,但默认的按值捕获确保divisor被拷贝进了lambda对应的所有闭包中,对吗?

错误,完全错误。

捕获只能应用于lambda被创建时所在作用域里的non-static局部变量(包括形参)。在Widget::addFilter的视线里,divisor并不是一个局部变量,而是Widget类的一个成员变量。它不能被捕获。而如果默认捕获模式被删除,代码就不能编译了:

void Widget::addFilter() const {
    filters.emplace_back([](int value) {  // 错误!divisor不可用
        return value % divisor == 0;
    });
}

另外,如果尝试去显式地捕获divisor变量(或者按引用或者按值——这不重要),也一样会编译失败,因为divisor不是一个局部变量或者形参。

void Widget::addFilter() const {
    filters.emplace_back([divisor](int value) {  // 错误!没有名为divisor局部变量可捕获
        return value % divisor == 0;
    });
}

所以如果默认按值捕获不能捕获divisor,而不用默认按值捕获代码就不能编译,这是怎么一回事呢?

解释就是这里隐式使用了一个原始指针:this。每一个non-static成员函数都有一个this指针,每次你使用一个类内的数据成员时都会使用到这个指针。例如,在任何Widget成员函数中,编译器会在内部将divisor替换成this->divisor。在默认按值捕获的Widget::addFilter版本中,

void Widget::addFilter() const {
    filters.emplace_back([=](int value) {
        return value % divisor == 0;
    });
}

真正被捕获的是Widget的this指针,而不是divisor。编译器会将上面的代码看成以下的写法:

void Widget::addFilter() const {
    auto currentObjectPtr = this;

    filters.emplace_back([currentObjectPtr](int value) {
        return value % currentObjectPtr->divisor == 0;
    });
}

明白了这个就相当于明白了lambda闭包的生命周期与Widget对象的关系,闭包内含有Widget的this指针的拷贝。特别是考虑以下的代码,参考第4章的内容,只使用智能指针:

using FilterContainer =
    std::vector<std::function<bool(int)>>;

FilterContainer filters;

void doSomeWork() {
    auto pw = std::make_unique<Widget>();

    pw->addFilter();
    ...
}  // 销毁Widget;filters现在持有悬空指针!

当调用doSomeWork时,就会创建一个过滤器,其生命周期依赖于由std::make_unique产生的Widget对象,即一个含有指向Widget的指针——Widget的this指针——的过滤器。这个过滤器被添加到filters中,但当doSomeWork结束时,Widget会由管理它的std::unique_ptr来销毁(见条款18)。从这时起,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;  // 使用副本
    });
}

但为什么要冒险呢?当一开始你认为你捕获的是divisor的时候,默认捕获模式就是造成可能意外地捕获this的元凶。

在C++14中,一个更好的捕获成员变量的方式时使用通用的lambda捕获:

void Widget::addFilter() const {  // C++14
    filters.emplace_back([divisor = divisor](int value) {  // 拷贝divisor到闭包
        return value % divisor == 0;  // 使用这个副本
    });
}

这种通用的lambda捕获并没有默认的捕获模式,因此在C++14中,本条款的建议——避免使用默认捕获模式——仍然是成立的。

使用默认的按值捕获还有另外的一个缺点,它们预示了相关的闭包是独立的并且不受外部数据变化的影响。一般来说,这是不对的。lambda可能会依赖局部变量和形参(它们可能被捕获),还有静态存储生命周期(static storage duration)的对象。这些对象定义在全局空间或者命名空间,或者在类、函数、文件中声明为static。这些对象也能在lambda里使用,但它们不能被捕获。但默认按值捕获可能会因此误导你,让你以为捕获了这些变量。参考下面版本的addDivisorFilter函数:

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;  // 引用上面的static
    });

    ++divisor;  // 调整divisor
}

归纳

  • 默认的按引用捕获可能会导致悬空引用

  • 默认的按值捕获对于悬空指针很敏感(尤其是this指针),并且它会误导人产生lambda是独立的想法

Previous6 lambda表达式Next条款32 使用初始化捕获来移动对象到闭包中

Last updated 2 years ago