陳碩 (giantchen_AT_gmail)
Blog.csdn.net/Solstice
本文主要討論 Linux x86/x86-64 平臺，偶爾會舉 Windows 作為反面教材。
C/C++ 的二進(jìn)制兼容性 (binary compatibility) 有多重含義，本文主要在“頭文件和庫文件分別升級，可執(zhí)行文件是否受影響”這個(gè)意義下討論，我稱之為 library （主要是 shared library，即動態(tài)鏈接庫）的 ABI (application binary interface)。至于編譯器與操作系統(tǒng)的 ABI 留給下一篇談 C++ 標(biāo)準(zhǔn)與實(shí)踐的文章。
什么是二進(jìn)制兼容性
在解釋這個(gè)定義之前，先看看 Unix/C 語言的一個(gè)歷史問題：open() 的 flags 參數(shù)的取值。open(2) 函數(shù)的原型是
int open(const char *pathname, int flags);
其中 flags 的取值有三個(gè)： O_RDONLY, O_WRONLY, O_RDWR。
與一般人的直覺相反，這幾個(gè)值不是按位或 (bitwise-OR) 的關(guān)系，即 O_RDONLY | O_WRONLY != O_RDWR。如果你想以讀寫方式打開文件，必須用 O_RDWR，而不能用 (O_RDONLY | O_WRONLY)。為什么？因?yàn)?O_RDONLY, O_WRONLY, O_RDWR 的值分別是 0, 1, 2。它們不滿足按位或。
那么為什么 C 語言從誕生到現(xiàn)在一直沒有糾正這個(gè)不足之處？比方說把 O_RDONLY, O_WRONLY, O_RDWR 分別定義為 1, 2, 3，這樣 O_RDONLY | O_WRONLY == O_RDWR，符合直覺。而且這三個(gè)值都是宏定義，也不需要修改現(xiàn)有的源代碼，只需要改改系統(tǒng)的頭文件就行了。
因?yàn)檫@么做會破壞二進(jìn)制兼容性。對于已經(jīng)編譯好的可執(zhí)行文件，它調(diào)用 open(2) 的參數(shù)是寫死的，更改頭文件并不能影響已經(jīng)編譯好的可執(zhí)行文件。比方說這個(gè)可執(zhí)行文件會調(diào)用 open(path, 1) 來寫文件，而在新規(guī)定中，這表示讀文件，程序就錯(cuò)亂了。
以上這個(gè)例子說明，如果以 shared library 方式提供函數(shù)庫，那么頭文件和庫文件不能輕易修改，否則容易破壞已有的二進(jìn)制可執(zhí)行文件，或者其他用到這個(gè) shared library 的 library。操作系統(tǒng)的 system call 可以看成 Kernel 與 User space 的 interface，kernel 在這個(gè)意義下也可以當(dāng)成 shared library，你可以把內(nèi)核從 2.6.30 升級到 2.6.35，而不需要重新編譯所有用戶態(tài)的程序。
所謂“二進(jìn)制兼容性”指的就是在升級（也可能是 bug fix）庫文件的時(shí)候，不必重新編譯使用這個(gè)庫的可執(zhí)行文件或使用這個(gè)庫的其他庫文件，程序的功能不被破壞。
見 QT FAQ 的有關(guān)條款：http://developer.qt.nokia.com/faq/answer/you_frequently_say_that_you_cannot_add_this_or_that_feature_because_it_woul
在 Windows 下有惡名叫 DLL Hell，比如 MFC 有一堆 DLL，mfc40.dll, mfc42.dll, mfc71.dll, mfc80.dll, mfc90.dll，這是動態(tài)鏈接庫的本質(zhì)問題，怪不到 MFC 頭上。
有哪些情況會破壞庫的 ABI
到底如何判斷一個(gè)改動是不是二進(jìn)制兼容呢？這跟 C++ 的實(shí)現(xiàn)方式直接相關(guān)，雖然 C++ 標(biāo)準(zhǔn)沒有規(guī)定 C++ 的 ABI，但是幾乎所有主流平臺都有明文或事實(shí)上的 ABI 標(biāo)準(zhǔn)。比方說 ARM 有 EABI，Intel Itanium 有 http://www.codesourcery.com/public/cxx-abi/abi.html，x86-64 有仿 Itanium 的 ABI，SPARC 和 MIPS 也都有明文規(guī)定的 ABI，等等。x86 是個(gè)例外，它只有事實(shí)上的 ABI，比如 Windows 就是 Visual C++，Linux 是 G++（G++ 的 ABI 還有多個(gè)版本，目前最新的是 G++ 3.4 的版本），Intel 的 C++ 編譯器也得按照 Visual C++ 或 G++ 的 ABI 來生成代碼，否則就不能與系統(tǒng)其它部件兼容。
C++ ABI 的主要內(nèi)容：
- 函數(shù)參數(shù)傳遞的方式，比如 x86-64 用寄存器來傳函數(shù)的前 4 個(gè)整數(shù)參數(shù)
- 虛函數(shù)的調(diào)用方式，通常是 vptr/vtbl 然后用 vtbl[offset] 來調(diào)用
- struct 和 class 的內(nèi)存布局，通過偏移量來訪問數(shù)據(jù)成員
- name mangling
- RTTI 和異常處理的實(shí)現(xiàn)（以下本文不考慮異常處理）
C/C++ 通過頭文件暴露出動態(tài)庫的使用方法，這個(gè)“使用方法”主要是給編譯器看的，編譯器會據(jù)此生成二進(jìn)制代碼，然后在運(yùn)行的時(shí)候通過裝載器(loader)把可執(zhí)行文件和動態(tài)庫綁到一起。如何判斷一個(gè)改動是不是二進(jìn)制兼容，主要就是看頭文件暴露的這份“使用說明”能否與新版本的動態(tài)庫的實(shí)際使用方法兼容。因?yàn)樾碌膸毂厝挥行碌念^文件，但是現(xiàn)有的二進(jìn)制可執(zhí)行文件還是按舊的頭文件來調(diào)用動態(tài)庫。
這里舉一些源代碼兼容但是二進(jìn)制代碼不兼容例子
- 給函數(shù)增加默認(rèn)參數(shù)，現(xiàn)有的可執(zhí)行文件無法傳這個(gè)額外的參數(shù)。
- 增加虛函數(shù)，會造成 vtbl 里的排列變化。（不要考慮“只在末尾增加”這種取巧行為，因?yàn)槟愕?class 可能已被繼承。）
- 增加默認(rèn)模板類型參數(shù)，比方說 Foo<T> 改為 Foo<T, Alloc=alloc<T> >，這會改變 name mangling
- 改變 enum 的值，把 enum Color { Red = 3 }; 改為 Red = 4。這會造成錯(cuò)位。當(dāng)然，由于 enum 自動排列取值，添加 enum 項(xiàng)也是不安全的，除非是在末尾添加。
給 class Bar 增加數(shù)據(jù)成員，造成 sizeof(Bar) 變大，以及內(nèi)部數(shù)據(jù)成員的 offset 變化，這是不是安全的？通常不是安全的，但也有例外。
- 如果客戶代碼里有 new Bar，那么肯定不安全，因?yàn)?new 的字節(jié)數(shù)不夠裝下新 Bar。相反，如果 library 通過 factory 返回 Bar* （并通過 factory 來銷毀對象）或者直接返回 shared_ptr<Bar>，客戶端不需要用到 sizeof(Bar)，那么可能是安全的。
- 如果客戶代碼里有 Bar* pBar; pBar->memberA = xx;，那么肯定不安全，因?yàn)?memberA 的新 Bar 的偏移可能會變。相反，如果只通過成員函數(shù)來訪問對象的數(shù)據(jù)成員，客戶端不需要用到 data member 的 offsets，那么可能是安全的。
- 如果客戶調(diào)用 pBar->setMemberA(xx); 而 Bar::setMemberA() 是個(gè) inline function，那么肯定不安全，因?yàn)槠屏恳呀?jīng)被 inline 到客戶的二進(jìn)制代碼里了。如果 setMemberA() 是 outline function，其實(shí)現(xiàn)位于 shared library 中，會隨著 Bar 的更新而更新，那么可能是安全的。
那么只使用 header-only 的庫文件是不是安全呢？不一定。如果你的程序用了 boost 1.36.0，而你依賴的某個(gè) library 在編譯的時(shí)候用的是 1.33.1，那么你的程序和這個(gè) library 就不能正常工作。因?yàn)?1.36.0 和 1.33.1 的 boost::function 的模板參數(shù)類型的個(gè)數(shù)不一樣，其中一個(gè)多了 allocator。
這里有一份黑名單，列在這里的肯定是二級制不兼容，沒有列出的也可能二進(jìn)制不兼容，見 KDE 的文檔：http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
哪些做法多半是安全的
前面我說“不能輕易修改”，暗示有些改動多半是安全的，這里有一份白名單，歡迎添加更多內(nèi)容。
只要庫改動不影響現(xiàn)有的可執(zhí)行文件的二進(jìn)制代碼的正確性，那么就是安全的，我們可以先部署新的庫，讓現(xiàn)有的二進(jìn)制程序受益。
- 增加新的 class
- 增加 non-virtual 成員函數(shù)
- 修改數(shù)據(jù)成員的名稱，因?yàn)樯a(chǎn)的二進(jìn)制代碼是按偏移量來訪問的，當(dāng)然，這會造成源碼級的不兼容。
- 還有很多，不一一列舉了。
歡迎補(bǔ)充
反面教材：COM
在 C++ 中以虛函數(shù)作為接口基本上就跟二進(jìn)制兼容性說拜拜了。具體地說，以只包含虛函數(shù)的 class （稱為 interface class）作為程序庫的接口，這樣的接口是僵硬的，一旦發(fā)布，無法修改。
比方說 M$ 的 COM，其 DirectX 和 MSXML 都以 COM 組件方式發(fā)布，我們來看看它的帶版本接口 (versioned interfaces)：
- IDirect3D7, IDirect3D8, IDirect3D9, ID3D10*, ID3D11*
- IXMLDOMDocument, IXMLDOMDocument2, IXMLDOMDocument3
換話句話說，每次發(fā)布新版本都引入新的 interface class，而不是在現(xiàn)有的 interface 上做擴(kuò)充。這樣一樣不能兼容現(xiàn)有的代碼，強(qiáng)迫客戶端代碼也要改寫。
回過頭來看看 C 語言，C/Posix 這些年逐漸加入了很多新函數(shù)，同時(shí)，現(xiàn)有的代碼不用修改也能運(yùn)行得很好。如果要用這些新函數(shù)，直接用就行了，也基本不會修改已有的代碼。相反，COM 里邊要想用 IXMLDOMDocument3 的功能，就得把現(xiàn)有的代碼從 IXMLDOMDocument 全部升級到 IXMLDOMDocument3，很諷刺吧。
tip：如果遇到鼓吹在 C++ 里使用面向接口編程的人，可以拿二進(jìn)制兼容性考考他。
解決辦法
采用靜態(tài)鏈接
這個(gè)是王道。在分布式系統(tǒng)這，采用靜態(tài)鏈接也帶來部署上的好處，只要把可執(zhí)行文件放到機(jī)器上就行運(yùn)行，不用考慮它依賴的 libraries。目前 muduo 就是采用靜態(tài)鏈接。
通過動態(tài)庫的版本管理來控制兼容性
這需要非常小心檢查每次改動的二進(jìn)制兼容性并做好發(fā)布計(jì)劃，比如 1.0.x 系列做到二進(jìn)制兼容，1.1.x 系列做到二進(jìn)制兼容，而 1.0.x 和 1.1.x 二進(jìn)制不兼容。《程序員的自我修養(yǎng)》里邊講過 .so 文件的命名與二進(jìn)制兼容性相關(guān)的話題，值得一讀。
用 pimpl 技法，編譯器防火墻
在頭文件中只暴露 non-virtual 接口，并且 class 的大小固定為 sizeof(Impl*)，這樣可以隨意更新庫文件而不影響可執(zhí)行文件。當(dāng)然，這么做有多了一道間接性，可能有一定的性能損失。見 Exceptional C++ 有關(guān)條款和 C++ Coding Standards 101.
Java 是如何應(yīng)對的
Java 實(shí)際上把 C/C++ 的 linking 這一步驟推遲到 class loading 的時(shí)候來做。就不存在“不能增加虛函數(shù)”，“不能修改 data member” 等問題。在 Java 里邊用面向 interface 編程遠(yuǎn)比 C++ 更通用和自然，也沒有上面提到的“僵硬的接口”問題。
(待續(xù))