我只是想將我的存檔中保存的一些舊的C++源代碼移植到iOS中，從而提供一個ObjC GUI，使用一些C++東西的包裝並保留重要數據在C++代碼中工作的東西。所以，問題是，舊的來源來自Win32 MFC，因此使用CString類的字符串，我想用Joe O'Leary的CStdString替換它，這是一個C++模板類，它會做得很好......但：在多個源代碼中將ObjC和C++與C++模板類混合使用
我必須使用字符串類定義以及大量不同的C++源代碼，因此它們每個都將包含CStdString模板。通常我會爲整個字符串類編寫一個包裝器，但如果我不需要，則會更好。
我會在實例化不同來源的字符串時遇到問題嗎？能否將一個模板化的字符串從一個源傳遞到另一個源？事實上，我不知道編譯器是否只爲模板生成一次或多次模板的代碼，而事實上該模板使用了相同的實例化類型。
你可以填補這一點？
謝謝...
我同意CString，只要你留在std :: string或C++的其他多平臺字符串實現你不會面臨任何問題（甚至在iOS上提升工作）。
我已經將C++/Obj-C集成了大約兩年，所以您可以確定保持模型類在C++中（即使是大量模板化代碼）也不是問題。我會建議你做Obj-C在Obj-C做的最好的事情，儘管......（避免成爲錘子開發者:)）
祝你好運！
MFC和CString只可以適當的Windows操作系統，所以他們沒有在任何類型的庫，這將潛在地使用非Windows平臺被推杆很好的候選人的工作。
我不熟悉的喬·奧利裏的CStdString類，但我會建議使用std::string儘可能和char*與"extern C"出口和包裝功能使用C++以外的土地爲C風格的字符串更容易與可能需要調用到C++庫中的其他語言兼容。
就模板而言，所有的變化都在編譯時生成，然後在運行時選擇正確的實現，據我所知。然而，你的問題很可能是從一種字符串翻譯到另一種字符串，這可能需要你創建一些中間層或包裝從字符串類型的一種語言編組到另一種語言。
那麼，喬的CStdString實際上是從std :: string派生的類。我已經使用過很多次了，今天我用了它的最新版本（它的日期是2005年，最後一次是我用了4年），並通過opaque指針測試了一個Obj-C封裝類。一切順利。所以字符串傳輸Obj-C <=> C++不是一個問題。使用這個類的主要方面是，我可以在CStdString上對CString進行typedef，並將其提供給大多數現有代碼，因爲在其他類中，我必須替換它，這是其中唯一使用的重要MFC類型。 – konran 2011-03-25 21:33:47
從STL字符串派生即''public std :: string'是一個壞主意，因爲'std :: basic_string'析構函數不是'virtual'。如果在他的實現中添加了任何成員，他的派生對象將不會被正確銷燬。 'std :: string'不是意圖也不是恰當地實現爲繼承的基類。 – AJG85 2011-03-25 22:15:13
謝謝，好點！無論如何，壞事 - 好東西：CStdString沒有自己的成員。對於std :: basic_string的一個/兩個字節的實例化來說，它是一個簡單的包裝器，具有MFC CString提供的大多數功能的便利性和廣泛的可用性。我在十多年前在Linux上使用它，在Win32上我無法使用MFC。 Joe的工作從1998年開始，在約7年內發展到約50人的幫助下。我認爲他們已經處理了模板中的不良副作用。 – konran 2011-03-25 23:42:12
你好Mr.Gando，這聽起來真不錯:-)因此，這意味着的std ::這是基類CStdString的確可以在同一個項目，因爲這是建立只有一次在代碼中包含不同來源的字符串？ - 您的最後忠告：好的，在此期間，我很熟悉的對象 - 但不應該意味着我願意重寫工作的C++代碼;-) – konran 2011-03-25 21:23:27
我同意的數量較大，便攜性也是很好的論據。您可以嘗試在您的xcode項目中刪除CString，看看會發生什麼。如果它依賴於Windows的東西，事情可能會出錯。讓我知道事情的後續。 – Goles 2011-03-25 23:04:19
好吧，我把你的多，申請模板註釋掉點包括爲YES ;-) 我的測試是不符合一大堆CPP來源，這將需要更多的時間。到現在我可以說，我可以在typedef定義CString的下降沒有編譯器錯誤，無泄漏（分析儀和儀器），我得到不錯的結果是這樣 回覆：） - ：.thgir OT薄膜電致發光MORF gnirts lamron一個SI SIHT – konran 2011-03-25 23:51:55