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

與此相對應，__declspec(dllimport), 將指明由動態鏈接庫導入符號，除了導入全局變量/類的靜態成員變量，很多時候可以忽略, 這個時候尋找符號的優先級將有所不同
 

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

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中的內聯函數全部失效

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

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

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

危害2:

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

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

由此想到的:

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

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

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

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

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

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

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

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

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