读书笔记 effective c++ Item 46 如果想进行类型转换,在模板内部定义非成员函数

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

Item 24中解释了为什么对于所有参数的隐式类型转换,只有非成员函数是合格的,并且使用了一个为Rati

nal 类创建的operator函数作为实例。在继续之前建议你先回顾一下这个例子,因为这个条款的讨论是对它的扩展,我们会对Item 24的实例做一些看上去无伤大雅的修改:对Rational和opeartor同时进行模板化:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
template<typename T>
class Rational {
public:
Rational(const T& numerator = 0, // see [Item 20](http://www.cnblogs.com/harlanc/p/6440868.html "Item 20") for why params
const T& denominator = 1); // are now passed by reference
const T numerator() const; // see [Item 28](http://www.cnblogs.com/harlanc/p/6512595.html "Item 28") for why return
const T denominator() const; // values are still passed by value,
... //[ Item 3](http://www.cnblogs.com/harlanc/p/6384546.html "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*现在变成了模板:

1
2
3
4
Rational<int> oneHalf(1, 2); // this example is from Item 24,
// except Rational is now a template
Rational<int> result = oneHalf * 2; // error! won’t compile

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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的时候,Ratinonal被实例化称Rational,作为这个过程的一部分,参数为Rational的友元函数operator被自动声明。作为一个被声明的函数(不是函数模板),编译器在调用它时就能够使用隐式类型转换函数(像Rational的非显示构造函数),这就是如何使混合模式调用成功的

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

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

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

1
2
3
4
5
6
7
8
9
template<typename T>
class Rational {
public:
...
friend
const Rational<T> operator*(const Rational<T>& lhs,
const Rational<T>& rhs);
...
};

然而,使用速写形式更加容易(更加大众化)。

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

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

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

1
2
3
4
5
6
7
8
9
10
11
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的代码会像下面这个样子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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)。这会像下面这个样子:

1
2
3
4
5
6
7
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. 总结

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