条款32：在未来时态下发展程序
未来式思维要加上一些额外的考虑：
a、提供完整的类——即使某些部分目前用不到。当新的需求进来，你不太需要回头去修改哪些类。
b、设计你的接口，使有利于共同的操作行为，阻止共同的错误。让类轻易地被正确运用，难以被错误运用。
c、尽量使你的代码一般化，除非有不良的巨大后果。
“未来式思维”可增加代码重用性、加强其可维护性、健壮性，并促使在一个“改变实乃必然”的环境中中有着优雅的改变。它必须与“目前的规范”取得平衡。
条款33：将非尾端类设计为抽象类
如果有两个具体类C1和C2，希望C2以public方式继承C1，应该将原本的双继承体系改为三类继承体系：产生一个新的抽象类A，并令C1和C2都以public方式继承A。
一般性的法则是：继承体系中的非尾端类应该是抽象类。如果使用外界供应的程序库，或许可以对此法则做点变通；但如果代码完全在你掌控之下，坚持这个法则，可以提高程序的可靠性、健壮性、可读性、可扩展性。
条款34：如何在同一个程序中结合C++和C
一、Name Mangling（名称重整）
Name mangling是一种程序，C++编译器通过它为程序内的每一个函数编出独一无二的名称。C语言并不需要，因为C语言中无法将函数名称重载。
//声明一个函数，名为drawLine：不要重整其名称 extern "C" void drawLine(int x1, int y1, int x2, int y2);
上述代码中的extern“C”告诉编译器，name mangling被压抑。如果其他语言写的函数，要在C++中使用，也是extern “C”来声明。
二、Statics的初始化
静态类对象、全局对象、namespace内的对象以及文件范围内的对象，其构造函数总是在main之前就获得执行。这个过程称为static initialization。
通过static initialization产生出来的对象，其析构函数必须在static destruction过程中被调用，这发生在main结束之后。
如果程序主要以C完成而C++只是个支持库， C++程序库中很可能会有静态对象，就需要在C++中也要写上main函数，这并不意味需要重写C代码，只要将C main重命名为realMain，然后让C++ main函数调用realMain。
extern "C" // 以C语言完成此函数
int realMain(int argc, char *argv[]);
//以C++语言完成此函数
int main(int argc, char *argv[]){
return realMain(argc, argv);
}
这么做时，最好加上注释来解释原因。
三、动态内存分配
动态内存分配的一般规则很简单：程序的C++部分使用new和delete，程序的C部分使用malloc（及其变种）和free。只要new分配的内存就用delete释放，malloc分配的内存就用free释放，那么就没问题。用free释放new分配的内存或用delete释放malloc分配的内存，会导致未定义的行为。所以，唯一要记住的是：严密地将你new/delete与malloc/free分隔开来。
四、数据结构的兼容性
不可能让C函数了解C++的特性的，它们的交互必须限定在C能够接受的范围。从数据结构的观点看：在C++和C之间对数据结构做双向交流应该安全－－前提那些结构的定义式在C和C++中都可编译。为C++ struct加上非虚函数，虽然不兼容与C，但可能不影响其兼容性，其它任何改变则几乎都会影响。
总结：
如果打算在同一程序中混用C++和C，记住以下几个简单守则：
a、确定C++和C编译器产生兼容的目标文件（object files）。
b、将双方都使用的函数申明为extern "C"。
c、如果可能，尽量在C++中撰写main。
d、总是以delete删除new返回的内存；总是以free释放malloc返回的内存。
e、将两个语言间的“数据结构传递”限制于C所能了解的形式；C++ structs如果内含非虚函数，不收此限制。
条款35：让自己习惯于标准C++语言
标准运行库的功能分为以下几个大项：
a、支持C标准函数库。
b、支持string类型。
c、支持本地化。
d、支持I/O。
e、支持数值应用。
f、支持广泛用途的容器和算法。
STL以三个概念为基础：containers,iterators和algorithms。Containers持有一系列对象。Iterators是一种类似指针的对象，可以遍历STL Containers。Algorithms是可作用于STL containers身上的函数，以iterators来协助工作。
版权声明：本文为博主原创文章，未经博主允许不得转载。