条款21：必须返回对象时，别妄想返回其reference
Don’t try to return a reference when youmust return an object
一旦程序员抓住对象传值的效率隐忧，很多人就会一心一意根除传值的罪恶。他们不屈不挠地追求传引用的纯度，但他们全都犯了一个致命的错误：他们开始传递并不存在的对象的引用。考虑一个用以表现有理数的类，包含一个函数计算两个有理数的乘积：
class Rational {
public:
Rational(int numerator = 0, int denominator = 1);
...
private:
int n, d; // 分子与分母
friend
const Rational operator*(const Rational& lhs, const Rational& rhs);
};
operator* 的这个版本以传值方式返回它的结果，需要付出对象的构造和析构成本。如果你能用返回一个引用来代替，就不需付出代价。但是，请记住一个引用仅仅是一个名字，一个实际存在的对象的名字。无论何时只要你看到一个引用的声明，应该立刻问自己它是什么东西的别名，因为它必定是某物的别名。以上述operator*为例，如果函数返回一个引用，它必然返回某个既有的而且包含两个对象相乘产物的Rational对象引用。
当然没有什么理由期望这样一个对象在调用operator*之前就存在。也就是说，如果你有
Rational a(1, 2); // a = 1/2
Rational b(3, 5); // b = 3/5
Rational c = a * b; // c should be 3/10
期望原本就存在一个值为3/10的有理数对象并不合理。如果operator*返回一个reference指向如此数值，它必须自己创建那个Rational对象。
函数创建新对象仅有两种方法：在栈或在堆上。如果定义一个local变量，就是在栈空间创建对象：
const Rational& operator*(constRational& lhs, const Rational& rhs)
{
Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
} //糟糕的代码！
这个函数返回一个指向result的引用，但是result是一个局部对象，在函数退出时被销毁了。因此这个operator*的版本不会返回指向一个Rational的引用，它返回指向一个过时的Rational，因为它已经被销毁了。任何调用者甚至只是对此函数的返回值做任何一点点运用，就立刻进入了未定义行为的领地。这是事实，任何返回一个指向局部变量引用（或指针）的函数都是错误的。
考虑一下在堆上构造一个对象并返回指向它的引用的可能性。基于堆的对象通过使用new创建：
const Rational& operator*(constRational& lhs, const Rational& rhs)
{
Rational *result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
return *result;
} //更糟的写法！
谁该队你用new创建出来的对象实施delete？
Rational w, x, y, z;
w = x * y * z; // 与operator*(operator*(x, y), z)相同
这里，在同一个语句中有两个operator*的调用，因此new被使用了两次，这两次都需要使用 delete来销毁。但是operator*的客户没有合理的办法进行那些调用，因为他们没有合理的办法取得隐藏在通过调用operator*返回的引用后面的指针。这绝对导致资源泄漏。
无论是在栈还是在堆上的方法，为了从operator*返回的每一个 result，我们都不得不容忍一次构造函数的调用，而我们最初的目标是避免这样的构造函数调用。我们可以继续考虑基于 operator*返回一个指向staticRational对象引用的实现，而这个static Rational对象定义在函数内部：
const Rational& operator*(constRational& lhs, const Rational& rhs)
{
static Rational result; // static对象，此函数返回其reference
result= ... ; // 将lhs乘以rhs，并将结果置于result内
return result;
} //又一堆烂代码！
bool operator==(const Rational& lhs,const Rational& rhs);
// 一个针对Rational所写的operator==
Rational a, b, c, d;
...
if ((a * b) == (c * d)) {当乘积相等时，做适当的相应动作；}
else {当乘积不等时，做适当的相应动作}
除了和所有使用static对象的设计一样可能引起的线程安全（thread-safety）的混乱，上面不管 a，b，c，d 的值是什么，表达式 ((a*b) == (c*d)) 总是等于 true！如果代码重写为功能完全等价的另一种形式，很容易了解出了什么意外：
if (operator==(operator*(a, b), operator*(c, d)))
在operator==被调用前，已有两个起作用的operator*调用，每一个都返回指向 operator*内部的staticRational对象的引用。两次operator*调用的确各自改变了staticRational对象值，但由于它们返回的都是reference，因此调用端看到的永远是static Rational对象的“现值”。
一个必须返回新对象的函数的正确方法就是让那个函数返回一个新对象。对于Rational的 operator*，这就意味着下面这些代码或在本质上与其等价的代码：
inline const Rational operator*(constRational& lhs, const Rational& rhs)
{return Rational(lhs.n * rhs.n, lhs.d * rhs.d);}
当然，你可能付出了构造和析构operator*的返回值的成本，但是从长远看，这只是为正确行为付出的很小代价。但万一代价很恐怖，你可以允许编译器施行最优化，用以改善出码的效率却不改变其可观察的行为。因此某些情况下operator*返回值的构造和析构可被安全的消除。如果编译器运用这一事实（它们也往往如此），程序将保持应有行为，而执行起来又比预期的更快。
总结：如果需要在返回一个引用和返回一个对象之间做决定，你的工作就是让那个选择能提供正确的行为。让你的编译器厂商去绞尽脑汁使那个选择成本尽可能地低廉。
· 绝不要返回一个local栈对象的指针或引用，绝不要返回一个被分配的堆对象的引用，如果存在需要一个以上这样的对象的可能性时，绝不要返回一个局部 static 对象的指针或引用。
条款22：将成员变量声明为private
Declare data members private
首先，我们将看看为什么数据成员不应该声明为 public；
然后，我们将看到所有反对public数据成员的理由同样适用于protected数据成员。
最后导出了数