友元函数是可以直接访问类的私有成员的非成员函数。它是定义在类外的普通函数,它不属于任何类,但需要在类的定义中加以声明,声明时只需在友元的名称前加上关键字friend,其格式如下:
friend 类型 函数名(形式参数);
友元提供了不同类的成员函数之间、类的成员函数与一般函数之间进行数据共享的机制。通过友元,一个不同函数或另一个类中的成员函数可以访问类中的私有成员和保护成员。c++中的友元为封装隐藏这堵不透明的墙开了一个小孔,外界可以通过这个小孔窥视内部的秘密。
友元的正确使用能提高程序的运行效率,但同时也破坏了类的封装性和数据的隐藏性,导致程序可维护性变差。
友元函数的声明可以放在类的私有部分,也可以放在公有部分,它们是没有区别的,都说明是该类的一个友元函数。
一个函数可以是多个类的友元函数,只需要在各个类中分别声明。
友元函数的调用与一般函数的调用方式和原理一致。
形式:
friend 类型名 友元函数名(形参表);
然后在类体外对友元函数进行定义,定义的格式和普通函数相同,但友元函数可以通过对象作为参数直接访问对象的私有成员。
如果我们决定一个函数必须被声明为两个类的友元则友元声明如下
class Window; // 只声明
class Screen
{
friend bool is_equal( Screen &, Window & );
// ...
};
class Window
{
friend bool is_equal( Screen &, Window & );
// ...
};
如果我们决定该函数必须作为一个类的成员函数并又是另一个类的友元,则成员函数声明和友元声明如下:
class Window;
class Screen
{
public:
// copy 是类 Screen 的成员
Screen& copy( Window & );
// ...
};
class Window
{
// copy 是类 Window 的一个友元
friend Screen& Screen::copy( Window & );
// ...
};
只有当一个类的定义已经被看到时它的成员函数才能被声明为另一个类的友元。这并不总是能够做到的。
例如如果Screen 类必须把Window 类的成员函数声明为友元,而Window类必须把Screen 类的成员函数声明为友元。该怎么办呢?在这种情况下可以把整个Window类声明为Screen 类的友元。
例如:
class Window;
class Screen
{
friend class Window;
// ...
};
Screen 类的非公有成员现在可以被Window 的每个成员函数访问。
(1) 友元关系不能被继承。
(2) 友元关系是单向的,不具有交换性。若类B是类A的友元,类A不一定是类B的友元,要看在类中是否有相应的声明。
(3) 友元关系不具有传递性。若类B是类A的友元,类C是B的友元,类C不一定是类A的友元,同样要看类中是否有相应的申明
说明如下:
1)必须在类的说明中说明友元函数,说明时以关键字friend开头,后跟友元函数的函数原型,友元函数的说明可以出现在类的任何地方,包括在private和public部分;
2)注意友元函数不是类的成员函数,所以友元函数的实现和普通函数一样,在实现时不用”::”指示属于哪个类,只有成员函数才使用”::”作用域符号;
3)友元函数不能直接访问类的成员,只能访问对象成员;
4)友元函数可以访问对象的私有成员,但普通函数不行;
5)调用友元函数时,在实际参数中需要指出要访问的对象;
6)类与类之间的友元关系不能继承;
7)一个类的成员函数也可以作为另一个类的友元,但必须先定义这个类。
成员函数和非成员函数最大的区别在于成员函数可以是虚拟的而非成员函数不行。
所以,如果有个函数必须进行动态绑定(见条款38),就要采用虚拟函数,而虚拟函数必定是某个类的成员函数。关于这一点就这么简单。如果函数不必是虚拟的,情况就稍微复杂一点。
例如有理数类:
class rational {
public:
rational(int numerator = 0,int denominator = 1);
int numerator() const;
int denominator() const;
private:
...
};
这是一个没有一点用处的类。(用条款18的术语来说,接口的确最小,但远不够完整。)所以,要对它增加加,减,乘等算术操作支持,但是,该用成员函数还是非成员函数,或者,非成员的友元函数来实现呢?
当拿不定主意的时候,用面向对象的方法来考虑!有理数的乘法是rational类自己该做的事情,所以,写一个成员函数把这个操作包到类中。
class rational {
public:
...
const rational operator*(const rational& rhs) const;
};
(如果你不明白为什么这个函数以这种方式声明——返回一个const值而取一个const的引用作为它的参数——参考条款21-23。)
条款21: 尽可能使用const
条款22: 尽量用“传引用”而不用“传值”
条款23: 必须返回一个对象时不要试图返回一个引用
可以很容易地对有理数进行乘法操作:
rational oneeighth(1,8);
rational onehalf(1,2);
rational result = onehalf * oneeighth; // 运行良好
result = result * oneeighth; // 运行良好
但不要满足,还要支持混合类型操作,比如,rational要能和int相乘。但当写下下面的代码时,只有一半工作:
result = onehalf * 2; // 运行良好
result = 2 * onehalf; // 出错!
//这是一个不好的苗头。记得吗?乘法要满足交换律。
//如果用下面的等价函数形式重写上面的两个例子,问题的原因就很明显了:
result = onehalf.operator*⑵; // 运行良好
result = 2.operator*(onehalf); // 出错!
对象onehalf是一个包含operator*函数的类的实例,所以编译器调用了那个函数。而整数 2 没有相应的类,所以没有operator*成员函数。编译器还会去搜索一个可以象下面这样调用的非成员的operator*函数(即,在某个可见的名字空间里的operator*函数或全局的operator*函数):
result = operator*(2,onehalf); // 错误!
但没有这样一个参数为int和rational的非成员operator*函数,所以搜索失败。
再看看那个成功的调用。它的第二参数是整数2,然而rational::operator*期望的参数却是rational对象。怎么回事?为什么2在一个地方可以工作而另一个地方不行?
秘密在于隐式类型转换。编译器知道传的值是int而函数需要的是rational,但它也同时知道调用rational的构造函数将int转换成一个合适的rational,所以才有上面成功的调用(见条款19)。换句话说,编译器处理这个调用时的情形类似下面这样:
const rational temp⑵; // 从2产生一个临时的rational对象
result = onehalf * temp; // 同onehalf.operator*(temp);
当然,只有所涉及的构造函数没有声明为explicit的情况下才会这样,因为explicit构造函数不能用于隐式转换,这正是explicit的含义。如果rational象下面这样定义:
class rational {
public:
explicit rational(int numerator = 0,int denominator = 1); //此构造函数为explicit
...
const rational operator*(const rational& rhs) const;
...
};
那么,下面的语句都不能通过编译:
result = onehalf * 2; // 错误!
result = 2 * onehalf; // 错误!
这不会为混合运算提供支持,但至少两条语句的行为一致了。
然而,我们刚才研究的这个类是要设计成可以允许固定类型到rational的隐式转换的——这就是为什么rational的构造函数没有声明为explicit的原因。这样,编译器将执行必要的隐式转换使上面 result 的第一个赋值语句通过编译。
实际上,如果需要的话,编译器会对每个函数的每个参数执行这种隐式类型转换。但它只对函数参数表中列出的参数进行转换,决不会对成员函数所在的对象(即,成员函数中的*this指针所对应的对象)进行转换。这就是为什么这个语句可以工作:
result = onehalf.operator*⑵; // converts int -> rational
而这个语句不行:
result = 2.operator*(onehalf); // 不会转换
// int -> rational
第一种情形操作的是列在函数声明中的一个参数,而第二种情形不是。
尽管如此,你可能还是想支持混合型的算术操作,而实现的方法应该清楚了:使operator*成为一个非成员函数,从而允许编译器对所有的参数执行隐式类型转换:
class rational {
... // contains no operator*
};
// 在全局或某一名字空间声明,
// 参见条款m20了解为什么要这么做
//运算符重载为了实现混合运算,即调用运算符的可以是类对象,也可以是基本数据,如普通整数
const rational operator*(const rational& lhs,const rational& rhs)
{
return rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}
//这样就
rational onefourth(1,4);
rational result;
result = onefourth * 2; // 工作良好
result = 2 * onefourth; // 万岁,它也工作了!
这当然是一个完美的结局,但还有一个担心:operator*应该成为rational类的友元吗?
这种情况下,答案是不必要。因为operator*可以完全通过类的公有(public)接口来实现。上面的代码就是这么做的。
这里还说明了一个关键问题:
//操作符可以重载成为普通函数
const Test operator+(const Test&lsh,const Test&rsh);
详见下面的例子:
#include
using namespace std;
class Add
{
public:
int para;
Add(int n):para(n) {}
protected:
private:
};
Add operator+(Add lsh,Add rsh) {
return lsh.para+rsh.para;
}
int main()
{
Add a(5);
Add b(6);
Add c = a+b;
cout<.para<;
return 0;
}
上面的例子输出11,说明了这点。
只要能避免使用友元函数就要避免,因为,和现实生活中差不多,友元(朋友)带来的麻烦往往比它(他/她)对你的帮助多。
成员的函数
然而,很多情况下,不是成员的函数从概念上说也可能是类接口的一部分,它们需要访问类的非公有成员的情况也不少。
让我们回头再来看看本书那个主要的例子,string类。如果想重载operator>>;和operator<<;来读写string对象,你会很快发现它们不能是成员函数。如果是成员函数的话,调用它们时就必须把string对象放在它们的左边:
// 一个不正确地将operator>>;和
// operator<<;作为成员函数的类
class string {
public:
string(const char *value);
...
istream& operator>>(istream& input);
ostream& operator<<(ostream& output);
private:
char *data;
};
string s;
s >> cin; // 合法,但有违常规
s << cout; // 同上
这会把别人弄糊涂。所以这些函数不能是成员函数。注意这种情况和前面的不同。这里的目标是自然的调用语法,前面关心的是隐式类型转换。
正确用法:
istream& operator>>(istream& input,string& string)
{
delete [] string.data;
read from input into some memory,and make string.data
point to it
return input;
}
ostream& operator<<(ostream& output, const string& string)
{
return output << string.data;
}
注意上面两个函数都要访问string类的data成员,而这个成员是私有(private)的。但我们已经知道,这个函数一定要是非成员函数。这样,就别无选择了:需要访问非公有成员的非成员函数只能是类的友元函数。本条款得出的结论
假设 f() 是想正确声明的函数,c 是和它相关的类:
(1)虚函数必须是成员函数。如果 f() 必须是虚函数,就让它成为 c 的成员函数。
(2)operator>>;和operator<<;决不能是成员函数。如果f是operator>>;或operator<<;让 f() 成为非成员函数。如果 f() 还需要访问c的非公有成员,让 f() 成为c的友元函数。
(3)只有非成员函数对最左边的参数进行类型转换。如果 f() 需要对最左边的参数进行类型转换,让 f() 成为非成员函数。如果 f() 还需要访问 c 的非公有成员,让 f() 成为 c 的友元函数。
(4)其它情况下都声明为成员函数。如果以上情况都不是,让f成为c的成员函数。
[1] 百度百科
http://baike.baidu.com/link?url=aZrILJL73dY0WqcGVoCnqof1rOjLX1AqTeDSei8SDKnllP5IHyNd7y26ceddiV-IgJTY3WTa3R72kaWd7LNsUq
[2] http://www.cnblogs.com/staring-hxs/p/3432161.html