原则46：需要类型转换时请为模版定义非成员函数

本原则要解决的问题是在泛型中让隐式转换发生在所有实参上。
泛型编程和普通编程相比的一个最大的不同是编译器无法预先知道泛型长成什么样子，也就是说它们在编译器眼中都是不明确的，因此编译器无法在编译期之前得知要使用的泛型具体化，从而编译器无法进行隐式转换。
使泛型具体化的唯一途径就是根据传进来的实参类型来确定，但是泛型从来不会根据实参类型进行隐式转换。在这里作者说的很绕，似乎是在说泛型机制在确定函数具体化的过程中有一个逻辑上的死循环。
在本原则中作者举的例子是这样的。一个接受两个相同类型形参的模版类成员函数，其中一个实参是可以让编译器判断出这个模版的具体化是怎样的，而另一个实参是要经过隐式类型转换才能适用于这个模版具体化。可是泛型机制不支持实参的隐式类型转换。
编译器想调用某个函数，它必须先知道这个函数确实存在。而这个函数存在的前提是它必须能够通过参数类型推导出来，这一条件的成立又必须是通过构造函数接收实参来实现的，可是只要接收的实参类型与构造函数的形参类型不一样，泛型机制也不进行隐式类型转换，结果还是无法知道该调用哪个函数，从而导致调用失败。
泛型类内的friend模版函数有个特性，那就是它可以被编译器当做特定的函数（我的理解）。在这里作者说类模版不依赖于模版实参推导，所以类模版总是能够在具体化时知道模版实参的类型。这句话我暂时不懂是什么意思。不过我想这应该先前所说的泛型机制不支持隐式类型转换吧，不支持自然就不存在实参推导，也就不依赖了嘛。所以这样看来作者想表达的是，只要类内有一个接口接收到来自外部的实参就可以导至类模版具体化friend作为其中一员也不例外，反正模版最终会被具体化，到时候各个参数都会清晰明了，friend作为这个过程的一部分也会清晰明了，具体化以后friend就不是函数模版了而是函数，这样它就允许隐式类型转换了。这就是所谓的混合式调用。
很奇怪，作者说如果在泛型类内有friend的声明式，在类外是无法提供这个friend的定义式的，这让我很迷惑。因为只在类内声明是可以通过编译的但是无法进行连接的。基于作者的理由，作者索性直接在泛型类内定义friend函数。
又因为如果friend定义在类内它必然就是一个内联函数，而内联函数不能很大。可是你不能保证功能函数不大，于是作者提出让这个friend去掉用另一个工具函数，这个工具函数也是泛型类的一个成员函数，同样的道理它对于编译器而言也是不可见的，但是因为它的主调函数是这个friend，friend函数能够接受隐式类型转换，所以这个工具函数也就能按照实参正常运作了。
总结：
当我们编写一个泛型类，把该类支持参数隐式转换的所有成员函数声明为friend。