STL 跨模塊 調用 異常 解決
百度了一天，現在把結論放上邊：
1、不要用STL(std::string屬于STL)來跨模塊傳輸數據，例如：dll(so)之間，dll(so)和exe(elf)之間。
解決方法：使用基本類型、數組、結構體，或者使用下面文章中的方法。
2、不要跨模塊申請和釋放內存。
解決方法：可以實現一個接口來釋放，其他方法參考下面。
今天用個測試exe調用了個dll，有個接口返回std::string，經調試發現掛在該函數return之后，懷疑是string不適合作為返回值，百度一番發現下面這篇解釋的很詳細。
用了很久的dll也會出問題，而且他們用沒事，他們用的是vs2010未升級，我懷疑是vs2010升級sp1后和之前的stl已經有所不同。看來stl的版本和編譯選項的不同會導致crash。
轉自http://blog.163.com/cp7618@yeah/blog/static/70234777201241154218989/
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
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內部，而不是讓它出現在接口當中。動態庫的接口越簡單越好，不好去傳太過復雜的東東是至理名言：）
下面這篇文章也不錯，收藏之。
http://www.hellocpp.net/Articles/Article/714.aspx
跨dll使用template/STL需要注意的問題
template 是個好東西啊 . 經典的 stl . 強悍的boost. 還有我自己寫的那個 ------- 該死的 ------- 資源管理器.
dynamic link也是個好東西啊. 在windows下叫dll, 在unix下叫so (share object) . 它能省下很多重新發布軟件帶來的麻煩.
但是當template 遭遇到dynamic link 時候, 很多時候卻是一場惡夢.
現在來說說一部分我已經碰到過的問題. 問題主要集中在內存分配上.
1>
拿STL來說, 自己寫模板的時候,很難免就用到stl. stl的代碼都在頭文件里. 那么表示著內存分配的代碼.只有包含了它的cpp 編譯的時候才會被決定是使用什么樣的內存分配代碼. 考慮一下: 當你聲明了一個vector<> . 并把這個vector<>交給一個 dll里的代碼來用. 用完后, 在你的程序里被釋放了. 那么如果你 在dll里往vector里insert了一些東西. 那么這個時候insert 發生的內存分配的代碼是屬于dll的. 你不知道這個dll的內存分配是什么. 是分配在哪里的. 而這個時候.釋放那促的動作卻不在dll里.....同時. 你甚至無法保證編譯dll的那個家伙使用的stl版本和你是完全一樣的..>
如此說來, 程序crash掉是天經地義的....
對策: 千萬別別把你的stl 容器,模板容器在 dll 間傳來傳去 . 記住string也是....
2>
你在dll的某個類里聲明了一個vector之類的容器. 而沒有顯式的寫這個類的構造和析構函數. 那么問題又來了.
你這個類肯定有操作這vector的函數. 那么這些函數會讓vecoter<>生成代碼. 這些代碼在這個dll里都是一致的. 但是別忘了.你沒有寫析構函數...... 如果這個時候, 別人在外面聲明了一個這樣的類.然后調用這個類的函數操作了這個vector( 當然使用者并不知道什么時候操作了vector) . 它用完了這個類以后. 類被釋放掉了. 編譯器很負責的為它生成了一份析構函數的代碼...... 聽好了.這份代碼并不是在 dll里 ... . 事情于是又和1>里的一樣了.... crash ......(可能還會伴隨著迷茫.....)
對策: 記得dll里每個類,哪怕式構造析構函數式空的. 也要寫到cpp里去. 什么都不寫也式很糟糕的.....同時,更要把任何和內存操作有關的函數寫到 .cpp 里...
3>
以上兩個問題似乎都是比較容易的-----只要把代碼都寫到cpp里去, 不要用stl容器傳來傳去就可以了.
那么第三個問題就要麻煩的多.
如果你自己寫了一個模板, 這個模板用了stl 容器..........
這個時候你該怎么辦呢?
顯然你無法把和內存分配相關的函數都寫到.cpp里去 . template的代碼都必須放到header file里.....
對策: 解決這個問題的基本做法是做一個stl 內存分配器 , 強制把這個模板里和內存分配相關的放到一個.cpp里去.這個時候編譯這個cpp就會把內存分配代碼固定在一個地方: 要么是dll. 要么是exe里...
模板+動態鏈接庫的使用問題還很多. 要千萬留心這個陷阱遍地的東西啊
不要在dll或lib的導出函數以string（cstring）作返回值
http://blog.sina.com.cn/s/blog_5119a7f90100ygzi.html
這是因為string和csting采用了Copy-On-Write技術，Copy-On-Write使用了“引用計數”，這是一種內存共享機制。
假設有一個動態鏈接庫（叫myNet.dll或myNet.so）中有這樣一個函數返回的是string類：
string GetIPAddress(string hostname)
{
static string ip;
……
……
return ip;
}
而你的主程序中動態地載入這個動態鏈接庫，并調用其中的這個函數：
main()
{
//載入動態鏈接庫中的函數
hDll = LoadLibraray(…..);
pFun =
//
string ip = (*pFun)(“host1”);
……
……
//釋放動態鏈接庫
FreeLibrary(hDll);
……
cout << ip << endl;
}