Bind 与 Lambda？

Question

我有一个关于首选哪种风格的问题：std::bind Vs lambda in C++0x。我知道它们以某种方式服务于不同的目的，但让我们举一个交叉功能的例子。

使用lambda：

uniform_int<> distribution(1, 6);
mt19937 engine;
// lambda style
auto dice = [&]() { return distribution(engine); };

使用bind：

uniform_int<> distribution(1, 6);
mt19937 engine;
// bind style
auto dice = bind(distribution, engine);

我们应该选择哪一个？为什么？与上述示例相比，假设情况更复杂。即一种相对于另一种的优点/缺点是什么？

Answer 1

C++0x lambda 是单态的，而 bind 可以是多态的。你不能让

auto f = [](auto a, auto b) { cout << a << ' ' << b; }
f("test", 1.2f);

a 和 b 之类的东西必须有已知的类型。另一方面，tr1/boost/phoenix/lambda 绑定允许您执行此操作：

struct foo
{
  typedef void result_type;

  template < typename A, typename B >
  void operator()(A a, B b)
  {
    cout << a << ' ' << b;
  }
};

auto f = bind(foo(), _1, _2);
f("test", 1.2f); // will print "test 1.2"

请注意，类型 A 和 B 在此未固定。只有当f被实际使用时才会推导出这两个。

Answer 2

正如您所说，bind 和 lambda 并不完全针对同一目标。

例如，对于使用和编写 STL 算法，lambda 显然是赢家，恕我直言。

为了说明这一点，我记得一个非常有趣的答案，在堆栈溢出上，有人询问十六进制幻数的想法（例如 0xDEADBEEF、0xCAFEBABE、0xDEADDEAD 等），并被告知如果他是真正的 C++ 程序员，他只会有下载英语单词列表并使用简单的 C++ 一行代码:)

#include <iterator>
#include <string>
#include <algorithm>
#include <iostream>
#include <fstream>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>

int main()
{
    using namespace boost::lambda;
    std::ifstream ifs("wordsEn.txt");
    std::remove_copy_if(
        std::istream_iterator<std::string>(ifs),
        std::istream_iterator<std::string>(),
        std::ostream_iterator<std::string>(std::cout, "\n"),
        bind(&std::string::size, _1) != 8u
            ||
        bind(
            static_cast<std::string::size_type (std::string::*)(const char*, std::string::size_type) const>(
                &std::string::find_first_not_of
            ),
            _1,
            "abcdef",
            0u
        ) != std::string::npos
    );
}

这段代码，在纯 C++98 中，打开英语单词文件，扫描每个单词并仅打印长度为 8 的带有 'a'、'b 的单词'、'c'、'd'、'e' 或 'f' 字母。

现在，打开 C++0X 和 lambda ：

#include <iterator>
#include <string>
#include <algorithm>
#include <iostream>
#include <fstream>

int main()
{
 std::ifstream ifs("wordsEn.txt");
 std::copy_if(
    std::istream_iterator<std::string>(ifs),
    std::istream_iterator<std::string>(),
    std::ostream_iterator<std::string>(std::cout, "\n"),
    [](const std::string& s)
    {
       return (s.size() == 8 && 
               s.find_first_not_of("abcdef") == std::string::npos);
    }
 );
}

这读起来仍然有点繁重（主要是因为 istream_iterator 业务），但比绑定版本简单得多:)

Answer 3

C++ 0x lamdba 语法比绑定语法更具可读性。一旦进入超过 2-3 级绑定，您的代码就会变得几乎不可读且难以维护。我更喜欢更直观的 lambda 语法。

Answer 4

lambda 的一个关键优点是它们可以静态引用成员函数，而 bind 只能通过指针引用它们。更糟糕的是，至少在遵循“itanium c++ ABI”（例如 g++ 和 clang++）的编译器中，指向成员函数的指针是普通指针大小的两倍。

因此，至少对于 g++，如果你执行类似 std::bind(&Thing::function, this) 的操作，你会得到一个大小为三个指针的结果，两个指针指向成员函数一个用于 this 指针。另一方面，如果您执行[this](){function()}，您将得到一个大小只有一个指针的结果。

std::function 的 g++ 实现最多可以存储两个指针，无需动态内存分配。因此，将成员函数绑定到 this 并将其存储在 std::function 中将导致动态内存分配，而使用 lambda 并捕获 this 则不会。

---

来自评论：

成员函数必须至少有 2 个指针，因为它必须存储一个函数指针，并且再加上至少 1 个元数据值，例如参数数量。 lambda 是 1 指针，因为它指向此数据，而不是因为它已被魔法去掉。

否

“指向成员函数的指针”（至少在“itanium C++ ABI”下，但我怀疑其他编译器是类似的）大小是两个指针，因为它存储了指向实际成员函数的指针（或 vtable 偏移量）虚拟成员函数）以及“this 指针调整”以支持多重继承。将 this 指针绑定到成员成员函数会产生一个大小为三个指针的对象。

另一方面，对于 lambda，每个 lambda 都有一个唯一的类型，并且有关要运行的代码的信息存储为类型的一部分，而不是值的一部分。因此，只有捕获需要存储为 lambda 值的一部分。至少在 g++ 下，按值捕获单个指针的 lambda 具有单个指针的大小。

lambda、指向成员函数的指针或绑定结果都不将参数数量存储为数据的一部分。该信息作为其类型的一部分存储。

std::function 的 g++ 实现有四个指针大小，它由一个指向“调用者”函数的函数指针、一个指向“管理器”函数的函数指针和一个大小为两个指针的数据区域组成。当程序想要调用存储在 std::function 中的可调用对象时，将使用“invoker”函数。当 std::function 中的可调用对象需要复制、销毁等时，将调用管理器函数

。当您构造或分配给 std::function 时，将通过模板生成调用程序和管理器函数的实现。这就是允许 std::function 存储任意类型的原因。

如果您分配的类型能够适合 std::function 的数据区域，那么 g++ 的实现（我强烈怀疑大多数其他实现）会将其直接存储在那里，因此不需要动态内存分配。

为了演示为什么在这种情况下 lambda 比绑定好得多，我编写了一些小测试代码。

struct widget
{
    void foo();
    std::function<void()> bar();  
    std::function<void()> baz();  
};

void widget::foo() {
    printf("%p",this);
}

std::function<void()> widget::bar() {
    return [this](){foo();};
}

std::function<void()> widget::baz() {
    return std::bind(&widget::foo, this);
}

我使用带有 -O2 和 -fno-rtti 的“armv7-a clang trunk”选项将其输入 godbolt，并查看了生成的汇编程序。我已经手动分离出了 bar 和 baz 的汇编器。我们首先看一下 bar 的汇编器。

widget::bar():
        ldr     r2, .LCPI1_0
        str     r1, [r0]
        ldr     r1, .LCPI1_1
        str     r1, [r0, #8]
        str     r2, [r0, #12]
        bx      lr
.LCPI1_0:
        .long   std::_Function_handler<void (), widget::bar()::$_0>::_M_invoke(std::_Any_data const&)
.LCPI1_1:
        .long   std::_Function_base::_Base_manager<widget::bar()::$_0>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)
std::_Function_handler<void (), widget::bar()::$_0>::_M_invoke(std::_Any_data const&):
        ldr     r1, [r0]
        ldr     r0, .LCPI3_0
        b       printf
.LCPI3_0:
        .long   .L.str
std::_Function_base::_Base_manager<widget::bar()::$_0>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation):
        cmp     r2, #2
        beq     .LBB4_2
        cmp     r2, #1
        streq   r1, [r0]
        mov     r0, #0
        bx      lr
.LBB4_2:
        ldr     r1, [r1]
        str     r1, [r0]
        mov     r0, #0
        bx      lr

我们看到，bar 本身非常简单，它只是用 this 指针的值以及指向调用者和管理器函数的指针填充 std::function 对象。 “invoker”和“manager”函数也非常简单，看不到动态内存分配，并且编译器已将 foo 内联到“invoker”函数中。

现在让我们看看 baz 的汇编程序：

widget::baz():
        push    {r4, r5, r6, lr}
        mov     r6, #0
        mov     r5, r0
        mov     r4, r1
        str     r6, [r0, #8]
        mov     r0, #12
        bl      operator new(unsigned int)
        ldr     r1, .LCPI2_0
        str     r4, [r0, #8]
        str     r0, [r5]
        stm     r0, {r1, r6}
        ldr     r1, .LCPI2_1
        ldr     r0, .LCPI2_2
        str     r0, [r5, #8]
        str     r1, [r5, #12]
        pop     {r4, r5, r6, lr}
        bx      lr
.LCPI2_0:
        .long   widget::foo()
.LCPI2_1:
        .long   std::_Function_handler<void (), std::_Bind<void (widget::*(widget*))()> >::_M_invoke(std::_Any_data const&)
.LCPI2_2:
        .long   std::_Function_base::_Base_manager<std::_Bind<void (widget::*(widget*))()> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation)
std::_Function_handler<void (), std::_Bind<void (widget::*(widget*))()> >::_M_invoke(std::_Any_data const&):
        ldr     r0, [r0]
        ldm     r0, {r1, r2}
        ldr     r0, [r0, #8]
        tst     r2, #1
        add     r0, r0, r2, asr #1
        ldrne   r2, [r0]
        ldrne   r1, [r2, r1]
        bx      r1
std::_Function_base::_Base_manager<std::_Bind<void (widget::*(widget*))()> >::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation):
        push    {r4, r5, r11, lr}
        mov     r4, r0
        cmp     r2, #3
        beq     .LBB6_3
        mov     r5, r1
        cmp     r2, #2
        beq     .LBB6_5
        cmp     r2, #1
        ldreq   r0, [r5]
        streq   r0, [r4]
        b       .LBB6_6
.LBB6_3:
        ldr     r0, [r4]
        cmp     r0, #0
        beq     .LBB6_6
        bl      operator delete(void*)
        b       .LBB6_6
.LBB6_5:
        mov     r0, #12
        bl      operator new(unsigned int)
        ldr     r1, [r5]
        ldm     r1, {r2, r3}
        ldr     r1, [r1, #8]
        str     r0, [r4]
        stm     r0, {r2, r3}
        str     r1, [r0, #8]
.LBB6_6:
        mov     r0, #0
        pop     {r4, r5, r11, lr}
        bx      lr

我们发现它几乎在每个方面都比 bar 的代码更糟糕。 baz 本身的代码现在长度增加了一倍以上，并且包含动态内存分配。

调用者函数不能再内联 foo 甚至直接调用它，而是必须经历调用成员函数指针的整个繁琐过程。

管理器功能也更加复杂，并且涉及动态内存分配。

Answer 5

lambda 的好处之一是，当您需要在现有函数之上添加一点大逻辑时，它们会更有用。

使用绑定，您被迫创建一个新的函数/方法/函子，即使逻辑只在这一处需要。您需要想出一个合适的名称，它可能会使代码更难以理解，因为它可能会让您拆分相关逻辑。

使用 lambda，您可以在 lambda 内添加新逻辑（但如果创建新的可调用对象有意义，则不必这样做）。

Answer 6

我认为这更多是一个品味问题。快速掌握新技术或熟悉函数式编程的人可能会更喜欢 lambda 语法，而更保守的程序员肯定会更喜欢 bind，因为它更接近传统的 C++ 语法。

这样的决定应该与将要使用该代码的人员协调做出，可能是通过多数投票来做出的。

但这并没有改变事实，lambda 语法更加强大和简洁。

Answer 7

C++0x lambda 本质上取代了绑定。没有什么是你可以绑定的，你不能重新创建一个简单的包装器 lambda 来实现相同的目的。一旦 lambda 支持广泛传播，std::tr1::bind 就会走 std::bind1st 等的路。这很好，因为由于某种原因，大多数程序员很难理解绑定。

Answer 8

从 C++20 开始（自 2009 年提出这个问题以来发布！），有第三种选择： “nofollow noreferrer”>std::bind_front。 （C++23 也有 std::bind_back。）这样使用：

auto dice = std::bind_front(distribution, engine);

它也可以用于成员函数：

struct MyType {
    void myFn();

    auto getBound() {
        return std::bind_front(&MyType::myFn, this);
    }
};

它不会遇到 std:bind 的一些问题：它有一个更简单的实现，因为它不允许重新组织参数的顺序，因此它更有可能被编译器优化，并且它具有移动感知能力，因此可以正确转发其参数。

然而，它仍然可能比 lambda 生成更多的代码，因为函数指针/成员函数指针存储为结果值的数据成员而不是其类型的一部分。我不认为这会对性能产生很大的影响，除非你处于绝对最紧密的循环中。