effective C++条款27,28

本文主要是介绍effective C++条款27,28，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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中，转型语法其实就下面两种形式

1. (T) expression
2. T (expression)

这两种形式本质上并无任何的区别，都是旧式的转型语法
在现在C++中，提供了四种新式转型方式

1. const_cast<T>( expression ) 通常用来讲对象的常量性移除，它也是唯一有此能力的操作符
2. dynamic_cast<T>( expression ) 主要用来执行“安全向下转型”，它是唯一无法由旧式语法执行的动作，也是唯一一个可能耗费重大运行成本的转型动作
3. reinterpret_cast<T>( expression ) 用来执行低级转换，这个操作符能够在非相关的类型之间转换。如其名字，interpret的释义是explain the meaning of (information, words, or actions).对于数据而言，其在内存中就是0和1，这一操作符能够按照我们所需要的类型去解释这串01数据串，所以这是一个编译器，操作系统相关的操作符，不具备移植性。
4. 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
}

请记住

1. 如果可以，尽量避免使用转型。特别是避免使用低效率的dynamic_cast。如果设计需要使用转型，试着修改为无需转型的替代设计
2. 如果转型是必需的，那么将其隐藏在某个函数背后。调用者可以直接调用该函数，而不需要自己去考虑转型操作
3. 不要使用旧式的转型。新式转型容易辨认，且职责明确，对于代码的后续维护有巨大的帮助

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);

调用者能够直接修改内部数据，这带给我们两个教训

1. 成员变量的封装性最多只等于返回其引用的函数的访问级别。在本例中，虽然成员变量ulhc被声明为private，但是其实际上却是public的变量。
2. 如果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的可能性降到最低

这篇关于effective C++条款27,28的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---