STL跨平臺(tái)調(diào)用出現(xiàn)異常的原因及解決辦法
STL跨平臺(tái)調(diào)用會(huì)出現(xiàn)很多異常，你可以試試. STL使用模板生成，當(dāng)我們使用模板的時(shí)候，每一個(gè)EXE，和DLL都在編譯器產(chǎn)生了自己的代碼，導(dǎo)致模板所使用的靜態(tài)成員不同步，所以出現(xiàn)數(shù)據(jù)傳遞的各種問題，下面是詳細(xì)解釋。
原因分析：
一 句話-----如果任何STL類使用了靜態(tài)變量（無論是直接還是間接使用），那么就不要再寫出跨執(zhí)行單元訪問它的代碼。?除非你能夠確定兩個(gè)動(dòng)態(tài)庫使用的 都是同樣的STL實(shí)現(xiàn)，比如都使用VC同一版本的STL，編譯選項(xiàng)也一樣。強(qiáng)烈建議，不要在動(dòng)態(tài)庫接口中傳遞STL容器！！
STL不一定不能在DLL間傳遞，但你必須徹底搞懂它的內(nèi)部實(shí)現(xiàn)，并懂得為何會(huì)出問題。
微軟的解釋：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b172396
微軟給的解決辦法：
http://support.microsoft.com/default.aspx?scid=kb%3ben-us%3b168958
1、微軟的解釋：
大 部分C++標(biāo)準(zhǔn)庫里提供的類直接或間接地使用了靜態(tài)變量。由于這些類是通過模板擴(kuò)展而來的，因此每個(gè)可執(zhí)行映像（通常是.dll或.exe文件）就會(huì)存在 一份只屬于自己的、給定類的靜態(tài)數(shù)據(jù)成員。當(dāng)一個(gè)需要訪問這些靜態(tài)成員的類方法執(zhí)行時(shí)，它使用的是“這個(gè)方法的代碼當(dāng)前所在的那份可執(zhí)行映像”里的靜態(tài)成 員變量。由于兩份可執(zhí)行映像各自的靜態(tài)數(shù)據(jù)成員并未同步，這個(gè)行為就可能導(dǎo)致訪問違例，或者數(shù)據(jù)看起來似乎丟失或被破壞了。
可能不太好懂，我舉個(gè)例子：假如類A
?
在動(dòng)態(tài)連接庫開發(fā)中要特別注意內(nèi)存的分配與釋放問題，稍不注意，極可能造成內(nèi)存泄漏，從而訪問出錯(cuò)。例如在某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對(duì)象std::string，并且在其中改變std::string的內(nèi)容，即發(fā)生了內(nèi)存的重分配問題,若在EXE中調(diào)用該函數(shù)會(huì)出現(xiàn)內(nèi)存訪問問題。主要是：因?yàn)镈LL和EXE的內(nèi)存分配方式不同，DLL中的分配的內(nèi)存不能在EXE中正確釋放掉。
解決這一問題的途徑如下：
一般情況下：構(gòu)建DLL必須遵循誰分配就由誰釋放的原則，例如COM的解決方案（利用引用計(jì)數(shù)），對(duì)象的創(chuàng)建（QueryInterface）與釋放均在COM組件內(nèi)部完成。在純C 環(huán)境下，可以很容易的實(shí)現(xiàn)類似方案。
在應(yīng)用STL的情況下，很難使用上述方案來解決，因此必須另辟蹊徑，途徑有二：
1、自己寫內(nèi)存分配器替代STL中的默認(rèn)分配器。
2、使用STLport替代系統(tǒng)的標(biāo)準(zhǔn)庫。
其實(shí)，上述問題在VC7及以后版本中，已得到解決，注意DLL工程和調(diào)用的工程一定要使用多線程DLL庫，就不會(huì)發(fā)生內(nèi)存訪問問題。
?
?
一個(gè)很奇怪的問題：DLL中使用std::string作為參數(shù)結(jié)果出錯(cuò)
STL
這段時(shí)間,在工程中將一些功能封裝成動(dòng)態(tài)庫,需要使用動(dòng)態(tài)庫接口的時(shí)候.使用了STL的一些類型作為參數(shù).
比方string,vector,list.但是在使用接口的時(shí)候.
class exportClass
{
? ???bool dll_funcation(string &str);
};
復(fù)制代碼
//上面這個(gè)類只是一個(gè)形式，具體內(nèi)容不寫出來了.這個(gè)類被導(dǎo)出
當(dāng)我在使用這個(gè)庫的時(shí)候.這樣寫代碼:
string str="":
exportClass tmp;
tmp.dll_function(str);
復(fù)制代碼
這個(gè)函數(shù)能成功調(diào)用.但是在函數(shù)里面會(huì)給這個(gè)數(shù)組附值.如果字符串太長,就會(huì)出錯(cuò).函數(shù)調(diào)用能成功,但是一旦str資源需要釋放的時(shí)候,資源就不能釋放了,提示釋放了錯(cuò)誤的內(nèi)存空間.
一點(diǎn)一點(diǎn)取掉這個(gè)函數(shù)的代碼.最后就剩下
str="qadasdasdasdsafsafas";
還是出錯(cuò)誤.
如果改成很短的字符串,就不會(huì)出錯(cuò)誤.
在這個(gè)時(shí)候,只能嘗試認(rèn)為是字符串的空間太小
最終我修改成這樣,錯(cuò)誤消失了.希望錯(cuò)誤真的是這個(gè)引起的
string str="":
str.resize(1000);
exportClass tmp;
tmp.dll_function(str);
?
今 天寫程序的時(shí)候要給一個(gè)模塊的dll傳遞一個(gè)參數(shù)，由于參數(shù)數(shù)量是可變的，因此設(shè)計(jì)成了vector
對(duì)于這個(gè)問題，兩種辦法：
1.傳遞vector指針
2.傳遞const vector
究其原因：
是因?yàn)関ector在exe和dll之間傳遞的時(shí)候，由于在dll內(nèi)可能對(duì)vector插入數(shù)據(jù)，而這段內(nèi)存是在dll里面分配的，exe無法知道如何釋放內(nèi)存，從而導(dǎo)致問題。而改成const類型后，編譯器便知道dll里不會(huì)改變vector，從而不會(huì)出錯(cuò)。
或 者可以說這是"cross-DLL problem."（This problem crops up when an object is created using new in one dynamically linked library (DLL) but is deleted in a different DLL）的一種吧。
對(duì)于STL，在DLL中使用的時(shí)候，往往存在這些問題，在網(wǎng)絡(luò)上搜集了下，這些都是要平時(shí)使用STL的時(shí)候注意的。
***************************************************************************************************************
引用http://www.hellocpp.net/Articles/Article/714.aspx
當(dāng)template 遭遇到dynamic link 時(shí)候, 很多時(shí)候卻是一場(chǎng)惡夢(mèng).
現(xiàn)在來說說一部分我已經(jīng)碰到過的問題. 問題主要集中在內(nèi)存分配上.
1>?
????? 拿STL來說, 自己寫模板的時(shí)候,很難免就用到stl. stl的代碼都在頭文件里. 那么表示著內(nèi)存分配的代碼.只有包含了它的cpp 編譯的時(shí)候才會(huì)被決定是使用什么樣的內(nèi)存分配代碼. 考慮一下: 當(dāng)你聲明了一個(gè)vector<> . 并把這個(gè)vector<>交給一個(gè) dll里的代碼來用. 用完后, 在你的程序里被釋放了.??? 那么如果你 在dll里往vector里insert了一些東西. 那么這個(gè)時(shí)候insert 發(fā)生的內(nèi)存分配的代碼是屬于dll的. 你不知道這個(gè)dll的內(nèi)存分配是什么. 是分配在哪里的.
而這個(gè)時(shí)候.釋放那促的動(dòng)作卻不在dll里.....同時(shí). 你甚至無法保證編譯dll的那個(gè)家伙使用的stl版本和你是完全一樣的..>
????? 如此說來, 程序crash掉是天經(jīng)地義的....?
????? 對(duì)策: 千萬別別把你的stl 容器,模板容器在 dll 間傳來傳去 . 記住string也是....
2>?
???? 你在dll的某個(gè)類里聲明了一個(gè)vector之類的容器. 而沒有顯式的寫這個(gè)類的構(gòu)造和析構(gòu)函數(shù). 那么問題又來了.
???? 你這個(gè)類肯定有操作這vector的函數(shù). 那么這些函數(shù)會(huì)讓vecoter<>生成代碼. 這些代碼在這個(gè)dll里都是一致的. 但是別忘了.你沒有寫析構(gòu)函數(shù)...... 如果這個(gè)時(shí)候, 別人在外面聲明了一個(gè)這樣的類.然后調(diào)用這個(gè)類的函數(shù)操作了這個(gè)vector( 當(dāng)然使用者并不知道什么時(shí)候操作了vector) . 它用完了這個(gè)類以后. 類被釋放掉了. 編譯器很負(fù)責(zé)的為它生成了一份析構(gòu)函數(shù)的代碼...... 聽好了.這份代碼并不是在 dll里 ... . 事情于是又和1>里的一樣了.... crash ......(可能還會(huì)伴隨著迷茫.....)
???? 對(duì)策: 記得dll里每個(gè)類,哪怕式構(gòu)造析構(gòu)函數(shù)式空的. 也要寫到cpp里去. 什么都不寫也式很糟糕的.....同時(shí),更要把任何和內(nèi)存操作有關(guān)的函數(shù)寫到 .cpp 里...
3>?
??? 以上兩個(gè)問題似乎都是比較容易的-----只要把代碼都寫到cpp里去, 不要用stl容器傳來傳去就可以了.
?? 那么第三個(gè)問題就要麻煩的多.
?? 如果你自己寫了一個(gè)模板, 這個(gè)模板用了stl 容器..........
?? 這個(gè)時(shí)候你該怎么辦呢?
顯然你無法把和內(nèi)存分配相關(guān)的函數(shù)都寫到.cpp里去 . template的代碼都必須放到header file里.....
?? 對(duì)策: 解決這個(gè)問題的基本做法是做一個(gè)stl 內(nèi)存分配器 , 強(qiáng)制把這個(gè)模板里和內(nèi)存分配相關(guān)的放到一個(gè).cpp里去.這個(gè)時(shí)候編譯這個(gè)cpp就會(huì)把內(nèi)存分配代碼固定在一個(gè)地方: 要么是dll. 要么是exe里...
模板+動(dòng)態(tài)鏈接庫的使用問題還很多. 要千萬留心這個(gè)陷阱遍地的東西啊
***************************************************************************************************************************
微軟關(guān)于這類問題的解釋：
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
?
?
總結(jié)：
字符串參數(shù)用char*，Vector用char**，
動(dòng)態(tài)內(nèi)存要牢記誰申請(qǐng)誰釋放的原則。
下載文檔
