27. 尽量少做转型动作
c++的设计目标之一是，保证“类型错误”绝不可能发生。即，如果我们的程序能顺利的通过编译，那么就意味着它一定不会在任何对象身上出现任何不安全的操作。
在大部分情况下，转型会破坏我们原有的类型系统，有可能会产生一些很隐晦的错误，所以我们需要慎重选择转型操作，尽量通过设计来避免转型
类型转换的底层工作
任何的一次类型转换，编译器都会编译出运行时期执行的码。
int x, y;
double z = static_cast<double>(x) / y ;
如这段代码所示，在计算机的底层，int 和double完全就是两个不同的底层表述。浮点数在运算时，通过会有FPU(浮点处理器) 这样的器件参与。
再如下面的例子
class A {
int a;
};
class B {
int b;
};
class C : public B, public A {
int c;
};
int main() {
C c;
A *pa = &c;
B *pb = &c;
std::cout << pa << " " << pb << std::endl;
}
这段代码在我的电脑上的输出是
0x63ff10 0x63ff0c
也就是同一个对象有两个物理地址，随着多继承体系中的父类更多，该变量能够拥有更多的地址。这一现象的原因在于对象在C++中有着特定的内存布局，所以我们应该避免写出基于特点内存布局的代码，以保证其可移植性
这就是一个比较隐晦的转型问题，有可能会踩在这个坑里出不来。
转型语法
在C中，转型语法其实就下面两种形式
(T) expressionT (expression)
这两种形式本质上并无任何的区别，都是旧式的转型语法
在现在C++中，提供了四种新式转型方式
const_cast<T>( expression )通常用来讲对象的常量性移除，它也是唯一有此能力的操作符dynamic_cast<T>( expression )主要用来执行“安全向下转型”，它是唯一无法由旧式语法执行的动作，也是唯一一个可能耗费重大运行成本的转型动作reinterpret_cast<T>( expression )用来执行低级转换，这个操作符能够在非相关的类型之间转换。如其名字，interpret的释义是explain the meaning of (information, words, or actions).对于数据而言，其在内存中就是0和1，这一操作符能够按照我们所需要的类型去解释这串01数据串，所以这是一个编译器，操作系统相关的操作符，不具备移植性。static_cast<T>( expression )这个是最简单的操作符了，它用来强制进行隐式转换，将其显式表现出来，使得代码更具备维护性。
使用新式的转换语法，对于转换的结果可控性更强，且更方便别人阅读，维护。其次，转型动作的目标越窄小，越容易找出出问题的地方。
转型会出现的问题
转型还会导致我们写出一些似是而非的代码。比如在上述底层工作中所讲到对象具有多地址的问题。此外，如果需要在子类方法中调用父类的方法，并将其作用于子类对象上，若使用转型操作，可能会写出下面的代码
class Window {
public:
virtual void test() {/* do Something */}
};
class specificWindow : public Window {
public:
virtual void test() {
static_cast<Window>(*this).test();
}
};
这一代码并不会将父类方法作用在子类身上，子类方法中的转型操作会返回当前子类base class的一个副本，而后在副本上调用Window::test
对于这一问题的解决方案是，直接调用父类的方法
void specificWindow ::test() {
Window::test();
// do something
}
请记住
- 如果可以，尽量避免使用转型。特别是避免使用低效率的
dynamic_cast。如果设计需要使用转型，试着修改为无需转型的替代设计 - 如果转型是必需的，那么将其隐藏在某个函数背后。调用者可以直接调用该函数，而不需要自己去考虑转型操作
- 不要使用旧式的转型。新式转型容易辨认，且职责明确，对于代码的后续维护有巨大的帮助
28.避免返回handles指向对象的内部成分
这里的handles指的是引用，指针和迭代器，这三个东西能够直接指向和修改数据。
考虑这样的一段代码
class Point{
public:
void setX(int val);
void setY(int val);
};
struct privData {
Point ulhc;
Point lrhc;
};
class Rectangle {
private:
std::share_ptr<privData> pData;
public:
Point& upperLeft() const { return pData->ulhc; }
Point& lowerRight() const { return pData->lrhc; }
};
这样的代码可以通过编译，但是问题在于，这是一份自相矛盾的代码。Rectangle提供的两个public函数都申明为了const，说明其目的仅仅是让调用者得知相关的坐标点，而不提供修改的功能。但是！这代码却又返回了两个内部数据的引用，所以调用者完全可以如下操作：
Rectangle rec;
/* do something*/
rec.upperLeft().setX(10);
调用者能够直接修改内部数据，这带给我们两个教训
- 成员变量的封装性最多只等于返回其引用的函数的访问级别。在本例中，虽然成员变量
ulhc被声明为private，但是其实际上却是public的变量。 - 如果
const成员函数传出了一个引用，该引用所指的数据存储于对象之外，那么这个函数的调用者可以修改到那个数据
若返回了一个指向对象内部的handles，其实是破坏了整个对象的封装性。也会导致虽然调用了const成员函数，但是却可以更改对象的内部状态。对于上述问题的解决，如果一定要返回一个handles， 其实只需要对返回类型加上const即可。
const Point& upperLeft() const { return pData->ulhc; }
const Point& lowerRight() const { return pData->lrhc; }
这里除了降低封装性这一风险，直接返回内部数据的handles，还有可能带来dangling handles(悬空handles)这一更为严重的事，即这一handles所指的对象不复存在。考虑这样的一份代码
class GUIObject { ... };
const Rectangle& boundingRect (const GUIObject &obj);
// 用户有可能这样去调用
GUIObject *gui;
const Point& pUpperLeft = &( boundingRect(*gui).upperLeft() );
等号的右边，对boundingRect的调用会返回一个临时的Rectangle对象，我们将其称为temp。随后的upperLeft作用于temp上，返回一个指向temp内部成分的引用。而后的pUpperLeft指向了这一个引用，初步一看，这一表达式好像没什么问题。但是其存在着一个很大的设计缺陷。因为等号右边的表达式结束之后，这个临时创建temp就被销毁了！所以pUpperLeft实际上是一个悬空的引用。
请记住
请尽量避免返回handles指向对象的内部。以免降低内部数据的封装性，并且能将悬空handles的可能性降到最低