最近的一個項目中遇到了調用別人的sdk接口（dll庫）而傳給我的是一個vector指針，用完之後還要我來刪除的情況。這個過程中首先就是在我的exe中將其vector指針轉爲相應指針再獲取vector中相應的數據問題，始終都獲得不了正確的數據，要麼就是一些非法的數據；另一個問題就是delete這個指針時候會產生相應異常（針對這個問題的思考：如果EXE和DLL都鏈接到DLL的C/C++運行期庫,那麼代碼將能夠很好地運行.但是,如果兩個模塊中的一個或者兩個鏈接到靜態C/C++運行期庫,那delete的操作就會失敗.）。這叫一個折騰的糾結啊
。蒐羅了一些網絡資料以備以後的參考學習：
（1）對於STL，在DLL中使用的時候，往往存在這些問題，在網絡上搜集了下，這些都是要平時使用STL的時候注意的。
（2） 從一個可執行程序中輸出模板實例，在另一個可執行程序中引入此實例。例如：MyLibrary.DLL將vector <MyClass> 指針回傳給MyProgram.EXE中的一個函數，需要在MyLibrary.DLL中輸出MyClass類和vector <MyClass> 。在MyProgram.EXE中引入它們後。就可以得到MyLibrary.DLL中靜態數據成員的一份Copy了。
這個是解決我這個問題的挺不錯的方法，但是併爲給予採納和驗證。畢竟爲了保險起見最終還是選擇了數組傳遞數據，但是還是要給予的原則是誰創建誰釋放。否則還是會出問題我這裏即便是調用delete[ ]objArray;這裏的delete的並不知道要刪除多大的內存，而這個要刪除多大的內存信息是在dll中保存着的，那個dll中的delete才知道。DLL中分配的內存DLL要負責釋放！（一個模塊分配的內存要在同一個模塊中釋放！）
***************************************************************************************************************************
微軟關於這類問題的解釋：
You may experience an access violation when you access an STL object through a pointer or reference in a different DLL or EXE
http://support.microsoft.com/default.aspx?scid=KB;en-us;q172396
How to export an instantiation of a Standard Template Library (STL) class and a class that contains a data member that is an STL object
http://support.microsoft.com/default.aspx?scid=KB;en-us;q168958
這個講解也不錯：http://blog.csdn.net/lewutian/article/details/6786193
原因分析：
一句話-----如果任何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
1、微軟的解釋：
大部分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.
1、保證資源的分配/刪除操作對等並處於同一個執行單元；
比如，可以把這些操作（包括構造/析構函數、某些容器自動擴容{這個需要特別注意}時的內存再分配等）隱藏到接口函數裏面。換句話說：儘量不要直接從dll中輸出stl對象；如果一定要輸出，給它加上一層包裝，然後輸出這個包裝接口而不是原始接口。
2、保證所有的執行單元使用同樣版本的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的情況下，很難使用上述方案來解決，因此必須另闢蹊徑，途徑有二：
1、自己寫內存分配器替代STL中的默認分配器。
2、使用STLport替代系統的標準庫。
其實，上述問題在VC7及以後版本中，已得到解決，注意DLL工程和調用的工程一定要使用多線程DLL庫，就不會發生內存訪問問題。