boost::reference_wrapper<T>有一个显式 T&构造函数，而std::reference_wrapper<T>有一个隐式构造函数。因此，在以下代码中：
foo = bar;
如果foo是 a boost::reference_wrapper，则代码将无法编译（这很好，因为与reference_wrapper实际引用的语义不同。
如果foo是 a std::reference_wrapper，代码将“重新绑定”foo对的引用bar（而不是像人们可能错误地期望的那样分配值）。
这可能会导致难以捉摸的错误...考虑以下示例：
在一些假设库的1.0版中：
void set_max(int& i, int a, int b) {
i = (a > b) ? a : b;
}
在新版本（1.1）中，set_max转换为模板以接受任何宽度（或 UDT）的整数，而无需更改接口：
template<typename T1, typename T2, typename T3>
void set_max(T1& i, T2 a, T3 b) {
i = (a > b) ? a : b;
}
最后，在一些使用该库的应用程序中：
// i is a std::reference_wrapper<int> passed to this template function or class
set_max(i, 7, 11);
在这个例子中，库改变了它的实现set_max而不改变调用接口。这会默默地破坏任何传递它的代码，std::reference_wrapper因为参数将不再转换为int&，而是“重新绑定”到一个悬空引用（a或b）。
我的问题：为什么标准委员会选择允许隐式转换（从T&到std::reference_wrapper<T>）而不是遵循boost并使T&构造函数显式？
编辑：（ 回应乔纳森维克利提供的答案）......
原始演示（在上面的部分中）有意简洁地展示细微的库更改如何导致使用std::reference_wrapper将错误引入应用程序。
reference_wrapper为了响应 Jonathan Wakely 的观点，提供了下一个演示以展示“通过接口传递引用”的真实合法用途。
- 来自开发商/供应商 A
类似于std::bind但假装它专门用于某些任务的东西：
template<typename FuncType, typename ArgType>
struct MyDeferredFunctionCall
{
MyDeferredFunctionCall(FuncType _f, ArgType _a) : f(_f), a(_a) {}
template<typename T>
void operator()(T t) { f(a, t); }
FuncType f;
ArgType a;
};
- 来自开发商/供应商 B
一个RunningMax函子类。在这个虚构库的 1.0 和 1.1 版本之间，实现RunningMax被更改为更通用，而没有更改其调用接口。出于本演示的目的，旧实现定义在命名空间中lib_v1，而新实现定义在lib_v2：
namespace lib_v1 {
struct RunningMax {
void operator()(int& curMax, int newVal) {
if ( newVal > curMax ) { curMax = newVal; }
}
};
}
namespace lib_v2 {
struct RunningMax {
template<typename T1, typename T2>
void operator()(T1& curMax, T2 newVal) {
if ( newVal > curMax ) { curMax = newVal; }
}
};
}
- 最后但并非最不重要的是，上述所有代码的最终用户：
一些开发人员使用供应商/开发人员 A 和 B 的代码来完成某些任务：
int main() {
int _i = 7;
auto i = std::ref(_i);
auto f = lib_v2::RunningMax{};
using MyDFC = MyDeferredFunctionCall<decltype(f), decltype(i)>;
MyDFC dfc = MyDFC(f, i);
dfc(11);
std::cout << "i=[" << _i << "]" << std::endl; // should be 11
}
请注意以下事项：
最终用户使用
std::reference_wrapper预期的方式。单独来看，没有任何代码有错误或逻辑缺陷，并且一切都与 Vendor B的库的原始版本完美配合。
boost::reference_wrapper 在升级库时将无法编译，而 std::reference_wrapper 默默地引入了一个可能会或可能不会在回归测试中发现的错误。
跟踪这样的错误将很困难，因为“重新绑定”不是诸如工具之类的工具会捕获的内存错误。
valgrind此外，滥用的实际站点std::reference_wrapper将在供应商B的库代码中，而不是最终用户的。
底线： boost::reference_wrapper通过将其构造函数声明为显式，似乎更安全T&，并且可以防止引入这样的错误。删除显式构造函数限制的决定std::reference_wrapper似乎为了方便而损害了安全性，这在语言/库设计中应该很少发生。