软件分发与C++
以源代码形式分发:
问题1: 每个可执行文件都将包含类库的代码, 浪费磁盘空间, 如果用户同时运行包含该类库的几个应用,浪费虚拟内存.
问题2: 一旦类库厂商发现了缺陷,没有任何办法可以替换部分实现代码
动态链接与C++
引入库不包含实际的代码,由链接器产生, 它包含一些引用,指向DLL的文件名和被引出的符号名.
有了引入库,机器码在硬盘上只保留一份
C++的可移植性
因为存在名字改编(name mangling), A编译器的客户不能与B编译器的引入库成功链接.
Extern “C” 是消除名字改编现象的经典技术, 但它不能用于成员函数.
在客户的链接器上做一些文章, 使用DEF(Module Definition File): 它允许引出符号被化名为不同的引入符号,库厂商可为不同的编译器产生专门定制的引入库.
A编译器产生的函数,它所抛出的异常,不能被B编译器生成的客户程序捕捉到.
封装性与C++
C++通过private 和public 关键字支持语法上的封装性, 但没有定义二进制层次上的封装性.
这是因为C++的编译模型要求客户的编译器必须能够访问与对象的内存布局有关的所有信息,这样才能构造类的实例, 或调用类的非虚成员函数. 这些信息包括对象的私有成员和公共成员的大小与顺序.
把接口从实现中分离出来
接口类应该只描述实现者希望客户知道的底层数据类型的面貌.
使用句柄类作为接口.
缺点: 每个新增的方法要增加两个函数调用, 易出错,且开销大
抽象基类作为二进制接口
假设1: 复合类型在运行时的表现形式对于不同的编译器往往会保持不变
假设2: 所有的编译器都强制使用同样的顺序传递函数参数并且堆栈的清理也按统计表的方式进行.
假设3: 某个给定平台的C++编译器都实现了同样的虚函数调用机制
抽象基类的要求:
方法为virtual
DLL引出一个全局函数,由它代表客户调用new, 使用extern “C”
增加一个Delete虚方法, 代替虚析构函数(因为它在vtal中的位置与编译器相关)
接口类的虚函数总是通过保存在vtbl中的函数指针被间接调用, 客户程序不需要在开发时候链接这些函数的符号名
运行时多态性
用户可以动态的装入DLL, 减少地址空间初始化的工作,而且如果对象实现代码如果没有真正被使用的话,DLL就不会被装入.
允许客户在不同的实现之间动态地作出选择
对象扩展性
若追加新的方法: 老客户得到新对象仍可工作,但新客户得到老对象不能调用新方法
允许实现类显露更多的接口:
一个接口继承另一个相关的接口, 让实现类继承多个不相关的接口
客户利用RTTI确保当前对象支持客户请求的功能
但RTTI与编译器相关, 为此
从每个接口的暴露一个通用的方法dynamic_cast(), 使之完成与dynamic_cast 相同的工作
资源管理
引用计数使用原则:
接口指针被复制时调用DuplicatePointer()
不再使用时调用DestroyPointer()
指针被看作是有独立生命周期的实体,所以客户不需要把哪个指针和哪个对象联系起来
允许对象自己管理自己的生命周期
