VC中有一個關鍵字__declspec(dllexport), 其目的很簡單，就是導出符號，供其它可執(zhí)行模塊使用，主要用于動態(tài)鏈接庫(DLL), 然而也可用于EXE模塊

與此相對應，__declspec(dllimport), 將指明由動態(tài)鏈接庫導入符號，除了導入全局變量/類的靜態(tài)成員變量，很多時候可以忽略, 這個時候?qū)ふ曳柕膬?yōu)先級將有所不同
 

當這兩個關鍵字配合類使用，將會產(chǎn)生比較尷尬的問題了

DLL:

struct __declspec(dllexport) A

{

    void TestInline()

{

    printf(“from dll\n”);

}

};

EXE:

struct __declspec(dllimport) A

{

void TestInline()

{

printf(“from exe\n”);

}

};

int main()

{

    A obj;

    obj.TestInline(); //輸出 “from dll”!

    return 0;

}

危害1:

A中的內(nèi)聯(lián)函數(shù)全部失效

這當然可以從符號鏈接表中發(fā)現(xiàn)鏈接符號的蹤跡來表明內(nèi)聯(lián)函數(shù)失效了，不過有一個更簡單的方法，我們可以在EXE的代碼中把”TestInline”內(nèi)聯(lián)函數(shù)的定義代碼加以簡單修改，讓其輸出其它的字符串測試，這個時候運行會發(fā)現(xiàn)，輸出的字符串仍然是”from dll”（注意編譯為”Release”發(fā)行版, DEBUG版會將內(nèi)聯(lián)函數(shù)作為普通函數(shù)處理）, 這就說明了，內(nèi)聯(lián)函數(shù)被完全忽略了。如果這個時候，還能想到”TestInline”的定義代碼還有什么作用的話，那就是白白消耗編譯的時間，編譯期間編譯器辛辛苦苦生成的代碼，鏈接器會毫不留情地忽略掉。

很顯然，忽略掉內(nèi)聯(lián)函數(shù)的代碼，會有一個直接的副作用，那就是使應用程序的運行期變緩慢，特別是內(nèi)聯(lián)函數(shù)被大量在循環(huán)內(nèi)調(diào)用，而這個內(nèi)聯(lián)當成普通函數(shù)處理了

C++運行庫中有大量的內(nèi)聯(lián)成員函數(shù)，除了模板類以外(當然，非完全特化的模板類不可能支持導出的)，基本上都是以導出類的形式導出，這樣也就意味著，動態(tài)鏈接C++運行庫的程序，這類內(nèi)聯(lián)函數(shù)全部失效，編譯時間可一點沒少。

危害2:

私有成員函數(shù)，以及原本不想導出的函數(shù)(沒有多少重用價值，導出后還要承擔維護版本兼容性的責任)，也被”不知不覺”
地導出了，對于私有(private)成員函數(shù), 導出到外面有什么用呢？占據(jù)了符號表的一個位置，可是誰又能調(diào)用到呢？
如果要想調(diào)用，看來要強制把private變?yōu)閜ublic了，但是VC的符號形成機制包含了public/private/protected,
也就是通過了編譯也無法通過鏈接，唯一可能的辦法就是，修改DLL頭文件，在類里面增加”friend”, 在EXE端，
改變共享庫DLL頭文件的辦法，很顯然不是個正規(guī)方案

另外，導出了這些“無法調(diào)用”的函數(shù)，也影響了鏈接器的優(yōu)化。對于這些函數(shù)，如果DLL模塊內(nèi)部也沒有調(diào)用到，
本可以完全把這些代碼優(yōu)化掉，但是由于導出，鏈接器將無能為力， 這也直接增加了DLL文件的體積

由此想到的:

MFC/ATL動態(tài)庫似乎了解到這個問題，所以，它們寧可一個一個成員函數(shù)進行符號導出，也沒有進行整個類的導出，
為什么它們不把這個方式推薦給VC動態(tài)運行庫呢？

VC傳統(tǒng)靜態(tài)鏈接運行庫的方式雖然有某種弊端，但是卻可以完全避開上述提到的問題，而且脫離了”版本型”DLL的依賴(MSVCR71.dll, MSVCP71.dll, MSVCR90.dll, MSVCP90.dll…), 對于這類DLL的依賴，將給以后程序升級帶來隱含并難以解決的問題，大家可以考慮如下情形

版本1：A.exe依賴于B.dll, 并且它們同時依賴于msvcp71.dll

版本2: 由于A采用了新的VC版本進行編譯，A.exe現(xiàn)在依賴于msvcp90.dll了，B.dll沒有升級，仍然依賴msvcp71.dll

這個時候，進程中的內(nèi)存結(jié)構產(chǎn)生了微妙的變化，舉例來說，原來msvcp71.dll中的全局變量（例如cout）同時被A.exe和B.dll使用。現(xiàn)在呢，A.exe使用的是msvcp90.dll中的cout, B.dll使用的還是msvcp71.dll中的cout, 這種耦合的變化，將會導致程序執(zhí)行邏輯的變化(如果你運氣好，也許會沒有問題的)，例如，如果你在A中設置了cout的格式，然后調(diào)用B的接口，最后B的接口通過cout輸出，版本2與版本1將會拿到不同的執(zhí)行效果(源代碼可一點沒變哦，僅僅是換了個編譯器編譯)。大型程序邏輯將是非常復雜的，看來還是不要升級編譯器進行編譯的好，因為這將導致dll依賴關系的變化，這真是個無奈的選擇

混合編譯選項 ”/clr” 看來要考慮允許靜態(tài)鏈接運行庫了(現(xiàn)在的VC版本只能動態(tài)鏈接運行庫的)，因為運行庫DLL存在版本和效率缺陷

大家有沒有發(fā)現(xiàn)LINUX操作系統(tǒng)下的so文件一般比windows下的要大很多，其中一個原因是這個模型相當于默認全部導出，即使是全局函數(shù)也是一樣，哪怕你臨時寫一個沒意義的函數(shù)，忘記去掉了，也一并導出，雖然你并沒有給”外界”頭文件，告訴這個接口如何被調(diào)用，但是這個接口已經(jīng)事實存在了。雖然這樣會簡化一些工作，但是個人覺得，是非常不負責任的，特別是現(xiàn)代的應用大都是多任務模塊化的，這樣做潛在地多吃掉不少內(nèi)存和硬盤，而且對于版本兼容性，將帶來麻煩。我對LINUX了解不多，不知道是否有支持指定導出函數(shù)的方法呢？

COM(Component Object Model), 也許有很多其它弊端，但卻解決了上述問題，而且可以拿掉DLL文件名中描述版本的丑陋數(shù)字

個人認為，發(fā)展C++的二進制接口標準ABI(Application Binary Interface)是非常重要的，COM應該算一個ABI標準吧。總是靜態(tài)地依賴源代碼作為可重用模塊，真的弊端很大，多任務時占用的磁盤和內(nèi)存也會增加。托管編程模型毫無疑問解決了這個問題，當然也帶來了其它方面的一些問題。C++在編程模型上可以說比托管編程模型要簡單很多，但缺少一個二進制標準。解決這個問題將比在語言層面增加幾個關鍵字要重要很多