轉載整理自：https://blog.csdn.net/qwertyupoiuytr/article/details/53999586，感謝原作者的分享
DLL動態鏈接庫是程序複用的重要方式，DLL可以導出函數，使函數被多個程序複用，DLL中的函數實現可以被修改而無需重新編譯和連接使用該DLL的應用程序。作爲一名面向對象的程序員，希望DLL可以導出類，以便在類的層次上實現複用。所幸的是，DLL確實也可以導出類。
然而事實卻沒這麼簡單，導出類的DLL在維護和修改時有很多地方必需很小心，增加成員變量、修改導出類的基類等操作都可能導致意想不到的後果，也許用戶更新了最新版本的DLL庫後，應用程序就再也不能工作了。這就是著名的DLLHell（DLL地獄）問題。
DLL地獄問題是怎麼產生的呢？看下面的例子，假設DLL有一個導出類ClassD：
class ClassD
{
public:
int GetInt()
{
return m_i;
}
private:
int m_i;
};
應用程序使用現在的代碼來使用這個類：
ClassD d;
printf(“%d”,d.GetInt());
程序進行正正常，沒有什麼問題。後來DLL需要升級，對ClassD進行了修改，增加了一個成員變量，如下：
class ClassD
{
public:
int GetInt()
{
return m_i;
}
private:
int m_i2;
int m_i;
};
把新的DLL編譯連接完成後，複製到應用程序目錄，這個倒黴的應用程序調用GetInt方法恐怕再也無法得正確的值了。事實上它還算幸運的，如果GetInt的實現改成如下這樣，那麼它馬上就要出錯退出了。
intClassD::GetInt() // 修改後
{
return m_i++;
}
這樣的事情，稱它是個地獄（Hell）一點也不誇張。爲什麼會出錯呢？我們要先從類實例的創建開始，看看使用一個類的工作過程。
首先，程序語句“ClassD d；”爲這個類申請一塊內存。這塊內存保存該類的所有成員變量，以及虛函數表。內存的大小由類的聲明決定，在應用程序編譯時就已經確定。
然後，當調用“d.GetInt()”時，把申請的這一塊內存做爲this指針傳給GetInt函數，GetInt函數從this指向的位置開始，加上m_i應有的偏移量，計算m_i所在的內存位置，並從該位置取數據返回。m_i相對this的偏移量是由m_i在類中定義的位置決定的，定義在前的成員變量在內存中也更靠前。這個偏移量在DLL編譯時確定。
當ClassD的定義改爲修改後的狀態時，有些東西變了。
第一個變的是內存的大小。因爲修改後的ClassD多了一個成員變量，所以內存也變大了。然而這一點應用程序並不知道。
第二個變的是m_i的偏移地址。因爲在m_i之前定義了一個m_i2，m_i的實現偏移地址實際已經靠後了。所以d.GetInt()訪問的將是原來m_i後面的那個位置，而這個位置已經超出原來那塊內存的後部範圍了。
很顯然，在更換了DLL後，應用程序還按原來的大小申請了一塊內存，而它調用的方法卻訪問了比這塊內存更大的區域，出錯在所難免。
同樣的情形還會發生在以下這些種情況中：
1）應用程序直接訪問類的公有變量，而該公有變量在新DLL中定義的位置發生了變化；
2）應用程序調用類的一個虛函數，而新的類中，該虛函數的前面又增加了一個虛函數；
3）新類的後面增加了成員變量，並且新類的成員函數將訪問、修改這些變量；
4）修改了新類的基類，基類的大小發生了變化；
等等，總言而之，一不小心，你的程序就會掉進地獄。通過對這些引起出錯的情況進行分析，會發現其實只有三點變化會引起出錯，因爲這三點是使用這個DLL的應用程序在編譯時就需要確定的內容，它們分別是：
1） 類的大小；
2） 類成員的偏移地址；
3） 虛函數的順序。
要想做一個可升級的DLL，必需避免以上三個問題。所以以下三點用來使DLL遠離地獄。
1，不直接生成類的實例。對於類的大小，當我們定義一個類的實例，或使用new語句生成一個實例時，內存的大小是在編譯時決定的。要使應用程序不依賴於類的大小，只有一個辦法：應用程序不生成類的實例，使用DLL中的函數來生成。把導出類的構造函數定義爲私有的(privated)，在導出類中提供靜態(static)成員函數(如NewInstance())用來生成類的實例。因爲NewInstance()函數在新的DLL中會被重新編譯，所以總能返回大小正確的實例內存。
2，不直接訪問成員變量。應用程序直接訪問類的成員變量時會用到該變量的偏移地址。所以避免偏移地址依賴的辦法就是不要直接訪問成員變量。把所有的成員變量的訪問控制都定義爲保護型(protected)以上的級別，併爲需要訪問的成員變量定義Get或Set方法。Get或Set方法在編譯新DLL時會被重新編譯，所以總能訪問到正確的變量位置。
3，忘了虛函數吧，就算有也不要讓應用程序直接訪問它。因爲類的構造函數已經是私有(privated)的了，所以應用程序也不會去繼承這個類，也不會實現自己的多態。如果導出類的父類中有虛函數，或設計需要（如類工場之類的框架），一定要把這些函數聲明爲保護的(protected)以上的級別，併爲應用程序重新設計調用該慮函數的成員函數。這一點也類似於對成員變量的處理。
如果導出的類能遵循以上三點，那麼以後對DLL的升級將可以認爲是安全的。
如果對一個已經存在的導出類的DLL進行維護，同樣也要注意：不要改動所有的成員變量，包括導出類的父類，無論定義的順序還是數量；不要動所有的虛函數，無論順序還是數量。
總結起來，其實是一句話：導出類的DLL不要導出除了函數以外的任何內容。聽起來是不是有點可笑呢！
事實上，建議你在發佈導出類的DLL的時候，重新定義一個類的聲明，這個聲明可以不管原來的類裏的成員變量之類的，只把接口函數列在類的聲明裏，如下面的例子：
class ClassInterface
{
privated:
ClassInterface();
public:
static ClassInterface * NewInstance();
int GetXXX();
void SetXXX();
void Function();
};
使用該DLL的應用程序用上面的定義作爲ClassInterface的頭文件，便不會有任何可能導致的安全問題。
DLL地獄問是歸根結底是因爲DLL當初是作爲函數級共享庫設計的，並不能真正提供一個類所必需的信息。類層上的程序複用只有Java和C#生成的類文件才能做到。