1. 问题的引入——将operator*模板化

Item 24中解释了为什么对于所有参数的隐式类型转换，只有非成员函数是合格的，并且使用了一个为Rational 类创建的operator*函数作为实例。在继续之前建议你先回顾一下这个例子，因为这个条款的讨论是对它的扩展，我们会对Item 24的实例做一些看上去无伤大雅的修改：对Rational和opeartor*同时进行模板化：

 template<typename T>

 class Rational {

 public:

 Rational(const T& numerator = , // see Item 20 for why params

 const T& denominator = );         // are now passed by reference

 const T numerator() const;          // see Item 28 for why return

 const T denominator() const; // values are still passed by value,

 ... //Item 3 for why they’re const

 };

 template<typename T>

 const Rational<T> operator*(const Rational<T>& lhs,

 const Rational<T>& rhs)

 { ... }

正如Item 24中讨论的，我们想支持混合模式的算术运算，所以我们想让下面的代码通过编译。这应该没有问题，因为我们在Item 24中使用了相同的代码。唯一的区别是Rational和operator*现在变成了模板：

 Rational<int> oneHalf(, );            // this example is from Item 24,

 // except Rational is now a template

 Rational<int> result = oneHalf * ; // error! won’t compile

2. 问题分析——模板参数演绎不能进行隐式转换

但事实上上面的代码不会通过编译，这就表明了模板化的Rational和非模板版本有些地方还是不一样的，确实是有区别的。在Item
24中，编译器知道我们尝试调用什么函数（带两个Rational参数的operator*），但是这里，编译器不知道我们想要调用哪个函数。相反，它们尝试确认从模板operator*中实例化出（也即是创建）什么样的函数。它们知道它们想实例化一些名字为operator*的函数，这些函数带有两个类型为Rational<T>的参数，但是为了进行实例化，它们必须确认T是什么。问题是他们不可能知道。

为了演绎出T类型，它们看到了调用operator*时传递的参数类型。在上面的例子中，两个参数类型分别是Rational<int>（oneHalf的类型）和int(2的类型)。每个参数进行单独考虑。

使用oneHalf进行演绎（deduction）很容易，operator*的第一个参数所需要的类型为Rational<T>，实际上这里传递给operator*的第一个参数的类型是Rational<int>，所以T必须为int。不幸的是，对其他参数的演绎就没有这么简单了，operator*的第二个参数所需要的类型也为Rational<T>，但是传递给operator*的第二个参数是一个int值。在这种情况下编译器该如何确认T是什么呢？你可能期望它们使用Rational<int>的非显示构造函数来将2转换为一个Rational<int>，这样就允许它们将T演绎成int，但是它们没有这么做。因为在模板参数演绎期间永远不会考虑使用隐式类型转换函数。这样的转换是在函数调用期间被使用的，所以在你调用一个函数之前，你必须知道哪个函数是存在的。为了知道这些，你就必须为相关的函数模板演绎出参数类型（然后你才能实例化出合适的函数。）但是在模板参数演绎期间不会通过调用构造函数来进行隐式转换。Item 24没有涉及到模板，所以模板参数的演绎不是问题。现在我们正在讨论C++的模板部分（Item
1）,这变为了主要问题。

3. 问题解决——使用友元函数

3.1 在类模板中声明友元函数——编译通过

我们可以利用如下事实来缓和编译器接受的对模板参数演绎的挑战：模板类中的一个友元声明能够引用一个实例化函数。这就意味着类Ration<T>能够为Ration<T>声明一个友元函数的operator*。类模板不再依赖于模板参数演绎（这个过程只应用于函数模板），所以T总是在类Ration<T>被实例化的时候就能被确认。所以声明一个合适的友元operator*函数能简化整个问题：

 template<typename T>

 class Rational {

 public:

 ...

 friend // declare operator*

 const Rational operator*(const Rational& lhs, // function (see

 const Rational& rhs); // below for details)

 };

 template<typename T>                                                              // define operator*

 const Rational<T> operator*(const Rational<T>& lhs, // functions  

 const Rational<T>& rhs)

 { ... }

现在我们对operator*的混合模式的调用就能通过编译了，因为当对象oneHalf被声明为类型Rational<int>的时候，Ratinonal<T>被实例化称Rational<int>,作为这个过程的一部分，参数为Rational<int>的友元函数operator*被自动声明。作为一个被声明的函数（不是函数模板），编译器在调用它时就能够使用隐式类型转换函数（像Rational的非显示构造函数），这就是如何使混合模式调用成功的。

3.2 关于模板和模板参数的速写符号

虽然代码能够通过编译，但是却不能链接成功。我们稍后处理，但是对于上面的语法我首先要讨论的是在Rational中声明operator*。

在一个类模板中，模板的名字能够被用来当作模板和模板参数的速写符号，所以在Rational<T>中，我们可以写成Rational来代替Rational<T>。在这个例子中只为我们的输入减少了几个字符，但是如果有多个参数或者更长的参数名字的时候，它既能减少输入也能使代码看起来更清晰。我提出这些是因为在上面的例子中operator*的声明用Rational作为参数和返回值，而不是Rational<T>。下面的声明效果是一样的：

 template<typename T>

 class Rational {

 public:

 ...

 friend

 const Rational<T> operator*(const Rational<T>& lhs,

 const Rational<T>& rhs);

 ...

 };

然而，使用速写形式更加容易（更加大众化）。

3.3 把友元函数的定义合并到声明中——链接通过

现在让我们回到链接问题。混合模式的代码能够通过编译，因为编译器知道我们想调用一个实例化函数（带两个Rational<int>参数的operator*函数），但是这个函数只在Rational内部进行声明，而不是被定义。我们的意图是让类外部的operator*模板提供定义，但是编译器不会以这种方式进行工作。如果我们自己声明一个函数（这是我们在Rational模板内部所做的），我们同样有责任去定义这个函数。在上面的例子中，我们并没有提供一个定义，这就是为什么连接器不能知道函数定义的原因。

最简单的可能工作的解决方案是将operator*函数体合并到声明中：

 template<typename T>

 class Rational {

 public:

 ...

 friend const Rational operator*(const Rational& lhs, const Rational& rhs)

 {

 return Rational(lhs.numerator() * rhs.numerator(), // same impl

 lhs.denominator() * rhs.denominator()); // as in

 } // Item 24

 };

确实这能够工作：对operator*的混合模式调用，编译，链接，运行都没有问题。

3.4 如此使用友元函数很意思

这种技术的有意思的地方是友元函数并没有被用来访问类的非public部分。为了使所有参数间的类型转换成为可能，我们需要一个非成员函数（Item 24在这里仍然适用）；并且为了让合适的函数被自动实例化出来，我们需要在类内部声明一个函数。在类内部声明一个非成员函数的唯一方法是将其声明为友元函数。这就是我们所做的，不符合惯例？是的。有效么？毋庸置疑。

4. 关于模板友元函数inline的讨论

正如在Item 30中解释的，在类内部定义的函数被隐式的声明为inline函数，这同样包含像operator*这样的友元函数。你可以最小化这种inline声明的影响：通过让operator*只调用一个定义在类体外的helper函数。在这个条款的例子中没有必要这么做，因为operator*已经被实现成了只有一行的函数，对于更加复杂的函数体，helper才可能是你想要的。“让友元函数调用helper”的方法值得一看。

Rationl是模板的事实意味着helper函数通常情况下也会是一个模板，所以在头文件中定义Rational的代码会像下面这个样子：

 template<typename T> class Rational; // declare

 // Rational

 // template

 template<typename T> // declare

 const Rational<T> doMultiply( const Rational<T>& lhs, // helper

 const Rational<T>& rhs);                                         // template

 template<typename T>

 class Rational {

 public:

 ...

 friend

 const Rational<T> operator*(const Rational<T>& lhs,

 const Rational<T>& rhs)                                          // Have friend

 { return doMultiply(lhs, rhs); }                // call helper

 ...                                                            

 };           

许多编译器从根本上强制你将所有的模板定义放在头文件中，所以你可能同样需要在你的头文件中定义doMultiply。（正如Item30解释的，这样的模板不需要inline）。这会像下面这个样子：

template<typename T> // define

const Rational<T> doMultiply(const Rational<T>& lhs, // helper

const Rational<T>& rhs) // template in

{ // header file,

return Rational<T>(lhs.numerator() * rhs.numerator(), // if necessary

lhs.denominator() * rhs.denominator());

}

当然，作为一个模板，doMultiply不支持混合模式的乘法，但是也不需要支持。它只被operator*调用，operator*支持混合模式操作就够了！从根本上来说，函数operator*支持必要的类型转换，以确保两个Rational对象被相乘，然后它将这两个对象传递到doMultiply模板的合适实例中进行实际的乘法操作。协同行动，不是么？

5. 总结

当实现一个提供函数的类模版时，如果这些函数的所有参数支持和模板相关的隐式类型转换，将这些函数定义为类模板内部的友元函数。