条款二十一:当必须返回对象时,别妄想返回其reference
当你理解条款20后,很可能出现一种过度使用的情况:只要看到是一个非内置类型,就去使用引用传值。举个书上的例子:
class Rational
{
private:
int numerator;
int denominator;
public:
Rational():numerator(0), denominator(1){}
friend const Rational& operator* (const Rational& r1, const Rational& r2){…}
};
numerator表示分子,denominator表示分母,这里我们需要把注意力放在operator*上,不是在它的形参上(用的const引用是完全正确的),而是在它的返回值上,这个带引用的返回值是一个巨大的bug。
我们可以设想一下实现:
friend const Rational& operator* (const Rational& r1, const Rational& r2)
{
Rational temp;
temp.numerator = r1.numerator * r2.numerator;
temp.denominator = r1.denominator * r2.denominator;
return temp;
}
这是一种最容易想到的实现方式,在栈上创建对象temp,分子、分母分别相乘后,将之返回。
但仔细再想想,调用函数真的能收到这个temp吗?它是在operator*函数调用时的栈上产生的,当这个函数调用结束后,栈上的temp也会被pop掉,换言之,temp的生命周期仅存在于operator*函数内,离开这个函数,返回的引用将指向一个已经不在的对象!
对此,VS编译器已经给出了warning,如下:
“warning C4172: returning address of local variable or temporary”
千万不能忽略它。
那既然栈上创建对象不行,还可以在堆上创建嘛(new出来的都是在堆上创建的),于是我们有:
friend const Rational& operator* (const Rational& r1, const Rational& r2)
{
Rational *temp = new Rational();
temp->numerator = r1.numerator * r2.numerator;
temp->denominator = r1.denominator * r2.denominator;
return *temp;
}
这下VS编译器没有warning了,之前在资源管理那部分说过,new和delete要配对,这里只有new,那delete了?delete肯定不能在这个函数里面做,只能放在外面,这样new和delete实际位于两个不同的模块中了,程序员很容易忘记回收,而且给维护也带来困难,所以这绝对不是一种好的解决方案。书上举了一个例子,比如:
Rational w, x, y, z;
w = x * y * z;
连乘操作会有两次new的过程,我们很难取得operator*返回的reference背后隐藏的那个指针。
当然,如果把new换成auto_ptr或者是shared_ptr,这种资源泄露的问题就可以避免。
栈上创建的临时对象不能传入主调模块,堆上创建的对象就要考虑资源管理的难题,还有其他解决方法吗?
我们还有static对象可以用,static对象位于全局静态区,它的生命周期与这个程序的生命周期是相同的,所以不用担心它会像栈对象那样很快消失掉,也不用担心它会像堆对象那样有资源泄露的危险。可以像这样写:
friend const Rational& operator* (const Rational& r1, const Rational& r2)
{
static Rational temp;
temp.numerator = r1.numerator * r2.numerator;
temp.denominator = r1.denominator * r2.denominator;
return temp;
}
这样写编译器同样不会报错,但考虑一下这样的式子:
Rational r1, r2, r3;
if(r1 * r2 == r1 * r3){…}
if条件恒为真,这就是静态对象做的!因为所有对象共享这个静态对象,在执行r1*r2时,temp的值为t1,但执行r1*r3之后,temp的值统一都变成t2了。它在类中只有一份,明白这个原因后就不难理解了。
既然一个static对象不行,那弄一个static数组?把r1*r2的值放在static数组的一个元素里,而把r1*r3放在static数组的另一个元素里?仔细想想就知道这个想法是多么的天马行空。
一个必须返回新对象的正确写法是去掉引用,就这么简单!
friend const Rational operator* (const Rational& r1, const Rational& r2)
{
Rational temp;
temp.numerator = r1.numerator * r2.numerator;
temp.denominator = r1.denominator * r2.denominator;
return temp;
}
该让编译器复制的时候就要放手去复制。
最后总结一下:
绝对不要返回pointer或reference指向一个local stack对象,指向一个heap-allocated对象也不是好方法,更不能指向一个local static对象(数组),该让编译器复制对象的时候,就让它去复制!
返回 在函数中创建的变量,不要用引用,就用复制就好。
条款二十二:将成员变量声明为private
class Clothes
{
public:
int price;
string name;
};
假设有一个衣服的类,里面的成员变量用来描述它的价格和衣服名。将之设为public的话,类外可以直接接触到price成员变量。这样很危险,因为客户端可以直接修改price了,卖衣服的商家就会不开心了。而将price设置成private,像这样:
class Clothes
{
private:
int price;
string name;
public:
int GetPrice()
{
return price;
}
};
price的访问需要经由GetPrice()的成员函数才能进行,类外客户端不能直接对price进行操作。从这里就可以看到将price设为private的三个好处:
- 可以对访问进行控制,对于一个变量,可以设置它为可读可写(同时提供get和set函数),亦可设置为只读(只提供get函数),甚至可以设置成为只写(只提供set函数)。
- 语法一致性。很多时候程序员在编程的时候都在想到底是Object.price呢,还是Object.price()呢?如果只能通过成员函数访问,就知道后面应该加上小括号了。
- 面向对象的三大基石之一——封装。商家修改了这个类,比如在商店门口公布了打折信息,那么只要在类中这样做:
int GetPrice()
{
return price * 0.9;
}
客户端完全不需要作任何修改。封装可以更直观地打一个比方,有两个同学A和B,他们都约自己的朋友去爬山,A约了10个人,而B只约了1个人,不凑巧天下雨了,爬山的计划只能暂时取消,需要通知自己的朋友,这时你想想,是A容易通知呢,还是B容易通知呢?
是的,很明显应该是B好解决问题一些。为什么呢?因为与它发生关系(爬山)的人最少,所以处理起来很方便(一句话,接触越少越容易维护)。这唯一的1个人就好比是成员函数,如果功能变更,只要修改这个成员函数就可以了,而不必修改类外任何代码。
好了,我们总结一下为什么要将成员变量声明为private而不是public的原因:
能够提供语法一致性,写代码的时候能够马上区分要不要加函数括号;
提供更好的访问控制,只读、只写还是可读可写,都容易控制;
封装,减少与外界接触的机会,方便修改和维护。
现在回答下一个问题:为什么protected不行?
如果不存在继承关系,protected的作用与private等同,除了本类之外,其他类或者类外都不能访问,但如果存在继承关系时,protected标识的成员变量,在它的子类中仍可以直接访问,所以封装性就会受到冲击。这时如果更改父类的功能,相应子类涉及到的代码也要修改,这就麻烦了。而如果使用private标识,则根据规则,所有private标识的变量或者函数根本不被继承的,这样就可以保护父类的封装性了,仍可以在子类中通过父类的成员函数进行访问。
书上说了这样一句话:“从封装的角度观之,其实只有两种访问权限:private(提供封装)和其他(不提供封装)。
最后总结一下:
- 切记将成员变量声明为private,这可赋予客户访问数据的一致性、可细微划分访问控制、允诺约束条件获得保证,并提供class作者以充分的实现弹性
- protected并不比public更具封装性
本文探讨了C++中返回对象的最佳实践,强调不应返回局部对象的引用或指针,而应考虑复制对象。同时,介绍了成员变量声明为private的重要性,以实现更好的封装性和访问控制。

1771

被折叠的 条评论
为什么被折叠?



