7.4 效率有了,弹性呢
传统的C++对象模型提供有效率的运行期支持.这份效率,再加上与C之间的兼容性,造成了C++的广泛被接受度.然而,在某些领域方面,像是动态共享函数库(dynamically shared libraries),共享内存(shared memory),以及分布式对象(distributed object)方面,这个对象模型的弹性还是不够.
动态共享函数库 (Dynamic Shared Libraries)
理想中,一个动态链接的shared library应该像"突然造訪"一样.也就是说,当应用程序下一次运行时,会透明化地取用新的library版本号.新的版本号不应该对旧的应用程序产生侵略性,应用程序也不应该须要为此又一次建造一次.可是,在眼下的C++对象模型中,假设新版的library中的 class object布局有所变更,上述的"library无侵略性"的说法就有待商榷了.这是由于 class 的大小以及其每个直接(或继承而来)的members的偏移量(offset)都在编译时期就应该固定(虚拟继承的members除外).这尽管带来效率,却在二进制层面影响了弹性.假设object布局改变,应用程序就必须又一次编译.
共享内存 (Shared Memory)
当一个shared library被载入,它在内存中的位置由runtime linker决定,一般而言与运行中的进程(process)无关.然而,在C++对象模型中,当一个动态的shared library支持一个 class object,当中含有 virtual functions(被放在shared memory中),上述说法便不对.问题并不在于"将该object放置于shared memory中"的那个进程,而在于"想要经由这个shared object附着并调用一个virtual function"的第二个或更后继的进程.除非
dynamic shared library被放置于全然同样的内存位置上,就像当初载入这个shared object的进程一样,否则 virtual function会死的非常难看,可能的错误包含segment fault或bus error.原因在于每个 virtual function在 virtual table中的位置已经被固定了.眼下的解决的方法是属于程序层面,程序猿必须保证让跨越进程的shared libraries有同样的坐落地址.至于编译系统层面上的解决的方法,势必要牺牲原本的 virtual
table实现模型所带来的高效率.