1樓：王哲
在3.0之後，本著「不重複造輪子」的觀念，我們大量使用了stl。目前的容器類是因為記憶體易用計數的問題，所以在stl上面封裝了一層。
在v3.2已經使用了stl的正規表示式。我覺得自己的程式設計能力無法超越stl（廢話，顯然不可能），當然和我一起做cocos2d-x的兄弟們也大致如此，所以3.
0之後能用stl的地方，我們就盡量用stl，避免重複造輪子。
2樓：唐小唐
從cocos2d-x 3.0版本開始，cocos2d-x的風格正在努力向標準c++看齊，原則上是鼓勵使用stl的，但cocos2d-x使用的是引用計數的記憶體管理方式，因此如果你的元素是引擎內建型別（由引擎進行記憶體管理），在容器選擇上優先用cocos::Vector和cocos::
Map；其它情況，盡量都使用stl。
另外，C++11引入右值引用的概念，大大減少了物件拷貝成本，因此為了避免自己管理記憶體，盡量在棧上儲存物件。
3樓：lhelpme
所有繼承自 ccobject 物件實體不要放到stl 容器裡面， 但是指標可以放。
因為物件本身如果放在stl容器中 ，在容器析構的時候，呼叫物件的析構函式，如果是指標則不會有這個問題。
容器存指標主要問題是，如果物件已經釋放，那麼容器中的指標值就會指向錯無效記憶體區域。
如果stl容器先於物件析構，則沒有問題。
4樓：
理論上是可以用STL的，但是最好將STL的應用限制在Model層，在View和Controller層不要使用STL。即把STL的部分和Cocos2d的部分隔離開。
因為STL的記憶體管理思路和Cocos2dx的記憶體管理思路完全不一樣，Cocos2dx本身的記憶體管理就有很多坑啦，你再加上STL，就更加複雜，一旦使用不當，很容易造成記憶體洩露。
5樓：cookiezby
3.0中就推薦使用 Vector Map Value了，原來的CCArray CCDictionary之類的結構就已經摒棄了，更加符合C＋＋的開發風格。
cocos2dx編譯helloworld太慢了？
最近我在開始使用cocos2d x 3.10開發專案時，也遇到這個問題 明明已經把引擎專案原始碼完整編譯好了依次，建立專案時，新專案的編譯還是會耗費了很多時間，儘管我的電腦裝了SSD，還是要20來分鐘，著實讓我著急 今天上午研究了一下，發現3.x版本建立專案並不是像2.x那樣引用已經編譯好的Coco...
cocos2dx 還有未來麼？
mikeworld 早期cocos2dx工具鏈不完善友好，需要配合一堆小工具使用，我是最早從cocos2dx 2.x版本做起的，UI用的cocos builder，現在是十分尷尬的存在，都不更新了，但是專案又不想重寫，所以還在湊合使用。後來cocos出過整合方案，但是好像不太好用，然後後來又做了新的...
Cocos2d x 會不會被 Creator帶到溝裡去？
2D 遊戲還是有市場的，但是cocos 感覺搞不過unity的樣子。creator做的比studio好用多了，至少是吸取 copy 了unity editor好的地方。 凌華彬 其實都是 hard choice，我們只能盡力做出抉擇，在我們認為正確的地方使用有限的資源。今天來看，Cocos2d x ...