標籤：相容性 運行 運行時 繼承 布局 memory 編譯 strong 包含
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實現模型所帶來的高效率.
C++物件模型——效率有了,彈性呢(第七章)
