第二章：C++ 概览
n对语言特征的细节理解——甚至有关一个语言的所有特征——也不能代替对该语言以及使用它的基本技术的全局性认识。
n最重要的问题并不在于某个语言究竟拥有多少特征，而在于它所拥有的特征是否足以在某个所希望的应用领域中支持某种所希望的程序设计风格：
n所有的特征必须清晰而又没地集成在语言之中。
n必须能组合使用这些特征去得到一种解决方案，如果无法做这样的组合，那就会要求而外的独立的特征。
n应尽可能减少荒谬的和“专用的”特征。
n任何特征的实现都不应该给未使用这种特征的程序强加明显的额外开销。
n用户只需要了解自己在写程序时所明确使用的那个语言子集。
过程式程序设计
n范型：
n确定你需要哪些过程，采用你能找到的最好的算法
※ 这是C语言早期的 使用方式。
模块程序设计
n范型：
n确定你需要哪些模块，将程序分为一些模块，使数据隐藏于模块之中。
※常用namespace封装具有相似特性的信息（声明、对象、函数等等）。
模块程序设计——分别编译
//file stack.h
namespace Stack {
void push(char);
char pop();
}
//file main.cpp
#include “stack.h” //获得界面
void f() {
Stack::push(‘c’);
if (Stack::pop() != ‘c’) error(“impossible”);
//file stack.cpp
#include “stack.h”
namespace Stack{
const int max_size = 200;
char v[max_size];
int top = 0;
}
※这样做有利于把用户的界面 与实现代码分开。只要提供给用户的界面在使用过程中保持不变，那么对该实现代码的修改就不会影响用户已经编译的目标码，从而不用再次编译。由此看来：把程序合理地分成不同的模块一方面利于代码的修改移植，另一方面利于理顺程序内部的逻辑关系。这种技术不可以应用于类的使用，因为如果类的使用界面和类 体的真实定义（在另外一个文件的类定义和实现）不同就有可能出现未知效果。
模块程序设计——异常处理
异常处理：
//main函数应该这样写
int main(int agc, char *agv) {
try {
/*…代码…*/
}
catch (…) { //处理程序中未知异常
cout << “Unknown error occur!!”<< endl;
}
}
数据抽象
n范型：
n确定你需要哪些类型，未每个类型提供完整的一组操作。
n这种类型的行为方式（几乎）与内部类型完全一样。这样的类型常常被称为抽象数据类型。
n在那些对于每个类型都只需要一个对象的地方，采用模块凡是实现数据隐藏风格的程序设计也就足够了，并不需要特别地定义一个新的类型。
n大部分（但不是全部）模块表示为用户定义类型更好些。
数据抽象——※抽象类型（1）
n定义用户自定义类型并且直接利用该类型的方法使得类的表示方式没有与用户界面分离，而且还让使用它的模块包含了一些没必要使用的private成员和该类型的局部变量。在类型不常改变，而且那些局部变量有确实提供了我们继续要的清晰性和效率的那些地方，这种方式完全可以接受，也是很理想的。但是如果我们需要将该类型的 用户与类型表示的修改完全隔离开，前面这种做法就不够好了。这时我们就需要抽象类型。
n其实，使用抽象类型的时候我们也需要舍弃一样东西。就是该类型的局部变量，因为在不知道一个类型表示的大小的情况下，我们就无法获得这个类型的真正的局部变量。于是，用这个解决方案能得到界面与表示的完全分离，这是需要放弃的就是真正的局部变量。
数据抽象——抽象类型（2）
例如我们先定义界面：
class Stack{
public:
class Underflow{};
class Overflow{};
virtual void push(char c) = 0;
virtual char pop() = 0;
};
该Stack以如下方式使用：
void f(Stack &s_ref) {
s_ref.push(‘c’);
if (s_ref.pop() != ‘c’) throw Bad_pop();
}//请注意f()如何使用Stack界面，完全忽略了实现的细节
//毫不奇怪，有关实现的所有东西都可以与前面那个具体//Stack类完全一样
