为什么std：：bind1st被认为是"almost unusable"？

Why might std::bind1st be considered "almost unusable"?

本文关键字：almost unusable std bind1st 为什么 认为是      更新时间：2023-10-16

在关于boost::bind的对话中，注意到std::bind1st在c++ 03中存在，但它"几乎不可用"。

我找不到任何可靠的证据来支持这个。

boost::bind文档说:

boost::bind是标准函数std::bind1ststd:: bind2nd 。它支持任意函数对象，函数，函数指针和成员函数指针，并且能够绑定任何参数指定一个特定的值或路由输入任意参数的位置。bind不放置任何对功能对象的要求;特别是，它不需要result_type， first_argument_type和 second_argument_type 标准typedef .

可能暗示这些限制确实适用于std::bind1st。

除了对参数数量的明显限制之外， boost::bind相对于std::bind1st/std::bind2nd的优势是什么?断言std::bind1st在c++ 03中"几乎不可用"有什么优点吗?

如果我们看一下c++ 03 20.3.6.1和20.3.6.2，那么我们就会看到，对于bind1st的函子实参，我们要求三个typedef s(对于结果类型，第一个和第二个实参)，并且结果操作符只接受一个实参。

这意味着我们不能简单地在普通函数指针上使用bind1st，因为它们没有那些typedef。此外，我们只能在二进制函数上使用bind1st，因为我们不支持更多的参数。此外，boost::bind 等具有能够重新排序参数的优势，当然，它不仅支持第一个参数。

在我看来，绑定器的大多数用例是用于自由函数和成员函数，而不是用于函数对象;因此，bind1st的使用是非常有限的(尽管可以通过使用ptr_fun等其他工具进行扩展，但这是否使其更可用是值得怀疑的)。当然，这只是基于个人经验，但有人可能想做一个谷歌代码搜索统计bind1st。

bind1st返回的函数调用操作符类型为

typename Operation::result_type
operator()(const typename Operation::second_argument_type& x) const;

对于绑定函数对象的引用参数和非常严格的c++ 03编译器(最近的版本更宽松)不起作用。c++ 03禁止引用到引用。

相关文章：