C++中string跨DLL失敗解決途徑

一、問題描述：

在一個MFC應用程序exe中，調用另外一個DLL中的函數，函數中的一個形參是string類型的，每次調用都會出現亂碼的狀況。

調用前：

調用後：

 

二、緣由分析：

 

      不一樣的模塊各自有一份C運行時庫代碼、或者根本沒有C運行時庫，致使了各個模塊會有各自的堆。若是在A堆中申請空間，到B堆中釋放就會有崩潰，在模塊A申請的空間，必須在模塊A中釋放。

       以STL的string爲例，經過修改編譯選項驗證了這個問題。string在賦值的時候須要釋放掉原來的內存空間，而後再申請新的內存空間存儲新的內容，若是跨模塊了，釋放的時候就存在「A模塊申請B模塊釋放」的問題，致使程序崩潰。

       當程序中有多個模塊時，必須保證全部模塊使用的C運行時庫是一致的。

 

3.解決方法：

將MFC項目的運行庫改成「多線程調試DLL(/MDd)」.

預處理器定義爲:_MBCS;%(PreprocessorDefinitions)

 

相關資料：https://blog.csdn.net/xuelangwin/article/details/53836327

MTd/MT調用的是靜態庫模式，這種模式下應用程序和動態庫中的堆是不共享的，各自使用各自的。它的內存分配原則是在庫中申請的內存只能在庫中釋放。

MDd/MD調用的是動態庫模式，這種模式下應用程序和動態庫都使用應用程序中的堆。申請和釋放的都是應用程序上堆的空間。

 

 

STL跨平臺調用會出現不少異常，你能夠試試.

STL使用模板生成，當咱們使用模板的時候，每個EXE，和DLL都在編譯器產生了本身的代碼，致使模板所使用的靜態成員不一樣步，因此出現數據傳遞的各類問題，下面是詳細解釋。

 

 

緣由分析：
一 句話-----若是任何STL類使用了靜態變量（不管是直接仍是間接使用），那麼就不要再寫出跨執行單元訪問它的代碼。 除非你可以肯定兩個動態庫使用的 都是一樣的STL實現，好比都使用VC同一版本的STL，編譯選項也同樣。強烈建議，不要在動態庫接口中傳遞STL容器！！

STL不必定不能在DLL間傳遞，但你必須完全搞懂它的內部實現，並懂得爲什麼會出問題。
微軟的解釋：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b172396
微軟給的解決辦法：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b168958

一、微軟的解釋：
大 部分C++標準庫裏提供的類直接或間接地使用了靜態變量。因爲這些類是經過模板擴展而來的，所以每一個可執行映像（一般是.dll或.exe文件）就會存在 一份只屬於本身的、給定類的靜態數據成員。當一個須要訪問這些靜態成員的類方法執行時，它使用的是「這個方法的代碼當前所在的那份可執行映像」裏的靜態成 員變量。因爲兩份可執行映像各自的靜態數據成員並未同步，這個行爲就可能致使訪問違例，或者數據看起來彷佛丟失或被破壞了。

可能不太好懂，我舉個例子：假如類A<T>有個靜態變量m_s，那麼當1.exe使用了2.dll中提供的某個A<int>對象時，因爲模板擴展機制，1.exe和2.dll中會分別存在本身的一份類靜態變量A<int>.m_s。
這 樣，假如1.exe中從2.dll中取得了一個的類A<int>的實例對象a，那麼當在1.exe中直接訪問a.m_s時，其實訪問的是 1.exe中的對應拷貝（正確狀況應該是訪問了2.dll中的a.m_s）。這樣就可能致使非法訪問、應當改變的數據沒有改變、不該改變的數據被錯誤地更 改等異常情形。

原文：
Most classes in the Standard C++ Libraries use static data members directly or indirectly. Since these classes are generated through template instantiation, each executable image (usually with DLL or EXE file name extensions) will contain its own copy of the static data member for a given class. When a method of the class that requires the static data member is executed, it uses the static data member in the executable image in which the method code resides. Since the static data members in the executable images are not in sync, this action could result in an access violation or data may appear to be lost or corrupted.

一、保證資源的分配/刪除操做對等並處於同一個執行單元；
   好比，能夠把這些操做（包括構造/析構函數、某些容器自動擴容{這個須要特別注意}時的內存再分配等）隱藏到接口函數裏面。換句話說：儘可能不要直接從dll中輸出stl對象；若是必定要輸出，給它加上一層包裝，而後輸出這個包裝接口而不是原始接口。

二、保證全部的執行單元使用一樣版本的STL運行庫。
   好比，所有使用release庫或debug庫，不然兩個執行單元擴展出來的STL類的內存佈局就可能會不同。

只要記住關鍵就是：若是任何STL類使用了靜態變量（不管是直接仍是間接使用），那麼就不要再寫出跨執行單元訪問它的代碼。

解決方法：
1. 一個能夠考慮的方案
好比有兩個動態庫L1和L2，L2須要修改L1中的一個map，那麼我在L1中設置以下接口
int modify_map(int key, int new_value);
若是須要指定「某一個map」，則能夠考慮實現一種相似於句柄的方式，好比能夠傳遞一個DWORD
不過這個DWORD放的是一個地址

那麼modify_map就能夠這樣實現：
int modify_map(DWORD map_handle, int key, int new_value)
{
    std::map<int, int>& themap = *(std::map<int, int>*)map_handle;
    themap[key] = new_value;
}

map_handle的值也首先由L1「告訴」L2:
DWORD get_map_handle();

L2能夠這樣調用:
DWORD h = get_map_handle();
modify_map(h, 1, 2);

2. 加入一個額外的層，就能夠解決問題。因此，你須要將你的Map包裝在dll內部，而不是讓它出如今接口當中。動態庫的接口越簡單越好，很差去傳太過複雜的東東是至理名言：）

 

在動態鏈接庫開發中要特別注意內存的分配與釋放問題，稍不注意，很可能形成內存泄漏，從而訪問出錯。例如在某DLL中存在這樣一段代碼：

extent "C" __declspec(dllexport) 
void ExtractFileName( const std::string& path //!< Input path and filename.
, std::string& fname //!< Extracted filename with extension.
)
{
std::string::size_type startPos = path.find_last_of('\\');
fname.assign(path.begin() startPos 1, path.end() );
}

在DLL中使用STL對象std::string，而且在其中改變std::string的內容，即發生了內存的重分配問題,若在EXE中調用該函數會出現內存訪問問題。主要是：由於DLL和EXE的內存分配方式不一樣，DLL中的分配的內存不能在EXE中正確釋放掉。

解決這一問題的途徑以下：
通常狀況下：構建DLL必須遵循誰分配就由誰釋放的原則，例如COM的解決方案（利用引用計數），對象的建立（QueryInterface）與釋放均在COM組件內部完成。在純C 環境下，能夠很容易的實現相似方案。

在應用STL的狀況下，很難使用上述方案來解決，所以必須另闢蹊徑，途徑有二：
一、本身寫內存分配器替代STL中的默認分配器。
二、使用STLport替代系統的標準庫。

其實，上述問題在VC7及之後版本中，已獲得解決，注意DLL工程和調用的工程必定要使用多線程DLL庫，就不會發生內存訪問問題。

 前段時間從網上下來一個有意思的代碼，用VS2010打開時須要將工程轉換爲2010的工程，轉化後卻出現了編譯不經過的問題，相似這樣的錯誤：c:\program files\microsoft visual studio 10.0\vc\atlmfc\include\afxver_.h(81): fatal error C1189: #error :  Please use the /MD switch for _AFXDLL builds。以前一直沒注意過MFC庫使用方式須要與運行時庫一致的問題，感受非常奇怪，後來搜索了一下才知道有這樣的問題。因此在此簡要的說明一下這樣的問題，以給你們提供一個參考。

        VS2010編譯器要求MFC庫使用方式須要與運行時庫需一致，不然會出現錯誤或者警告。

        若是使用MFC動態庫，則要使用動態的運行時庫；若是使用MFC靜態庫，則要使用靜態的運行時庫。同時，若是工程是Debug配置，則要用調試版本的運行時庫；若是是Release配置，則要調用非調試版本的運行時庫，具體對應關係，以下所示：（D-DLL，d-Debug）

       

 一、在共享 DLL 中使用 MFC（運行時庫確定要用動態的運行時庫）

          Debug配置  -->  Multi-threaded Debug DLL(/MDd)

          Release配置  -->  Multi-threaded DLL(/MD)

 

 二、在靜態庫中使用 MFC（運行時庫確定要用靜態的運行時庫）

          Debug配置  -->  Multi-threaded Debug(/MTd)

          Release配置  -->  Multi-threaded(/MT)