cocos2d-x 是豆腐渣項目嗎？

01-12

看了代碼，我才發現這個框架寫的人一定是既沒熟悉 Objective-C 也沒熟悉 C++。
宏定義一堆，但是都是沒必要的、沒多大用途的，其實可以封裝下的
#define CREATE_FUNCTION 是 C 的用例，不是 C++ 的用例
在 C++ 有對象的語言上進行宏替換我也是挺佩服的，而且還要做返回值。沒考慮過兩者 bridge 會出錯的情況。

可以聯想到開發者本人不清楚自己是在寫 C 還是 CPP，正確用法應該是用 template 抽象。
解決上述問題，加 dynamic_cast，還要非空判斷，不然怕空指針返回了個空 Scene。
你確定編譯器、語法 parser 一定能把 CREATE_FUNC 很好地轉換成 static create？
用 C 的思想寫 CPP 本身就是有問題的，用 ObjC 的習慣來寫 CPP 也是有問題的。
首先 objc init 的是 self，不是 parent，生搬硬套，同理也沒有考慮 Cpp 跟 C 不是同一門語言，Cpp 比 C 多了更強的類型系統，你去把類型強制當作新類型去 init 是有問題的。你以為 Cpp 是跟 C 一樣隨便用 (Type) var 的語法給你 cast 呀？
然後整個編輯器都是錯誤提示，我感覺這框架根本沒法用，似乎達到需要重寫的感覺，求解決方案。

很多回答的人沒看圖發現 CREATE_FUNCTION 宏替換 inline function 作為類的靜態構造方法之後的產物在 clang 是不認帳嗎？然後 init 應該是 parent init 而不是 subclass init。所以安全情況當然要 cast 到 parent 再 init。靜態構造方法也如此，你自己看 CREATE_FUNCTION 是 __TYPE__ 宏替換的，所以 clang 識別出來認為這個靜態函數返回的是子類類型本身，而不是父類，所以 cast 一下就好。你要強制類型轉換在 cpp 是不合格的，那是 C 的習慣，所以 OC 裡面直接強轉指針沒問題，所以用在這裡肯定噴。你以為這裡是 Java？就算是 Java，你應該知道 unchecked warnings 會警告你的。
說明你自己從來寫代碼不去確認指針直接用，然後去一定保證自己的代碼一定行為正確性。

另外，我截圖所生成的圖，都不是我寫的，你試一下 cocos new 一個 HelloWorld -l cpp 出來自己看就知道了。
所以，【我是啥代碼都沒寫，一個新工程就已經一堆 Error 了】。template 是為了彌補 Cpp 早期 RTTI 不強的時候類型處理的問題，同時也可以在關閉 RTTI 的時候得到一些 OOP 的好處——「模塊復用」，更好去通過一個 template 模塊創建其它派生的模塊。
define 沒有完全不該用的地方，只是它用這個 inline function 去替換一個類的靜態工廠方法，我只是提出 Cpp 有 template 的工廠你幹嘛不用要去 define 一個 inline function 來做工廠？Cpp 在類型上做了很多強化，你用一個很傳統的 inline function 來替換帶類型的方法，最終必然導致這個宏只能替換成單一類型的結果，【通過這個 Error 說明編譯器不會繼續檢測替換結果的函數的返回值的類型是否為父類的派生】。
另外，CREATE_FUNCTION 的 pRet-&>autorelease 的 pRet 是指向 cocos2d::Ref，你可以試著把這堆宏放出來到獨立寫的 create 靜態方法，它會有「pRet 不兼容 cocos2d::Ref」警告。
總之，【一堆 C 下來的弱類型思想去嵌套 Cpp 的面向對象部分的強類型思想，是錯誤的！】。要不然我幹嘛跟你說要用 template，因為 template 才適用於 Cpp 的帶 RTTI 識別的思想。
【誰是初級程序員，已經明了。】——這句話放在後面，沒有任何意義。
因為，這不是初級不初級的問題，有工作經驗的程序員，可能他們比較習慣於某種他們自有的風格，已經有人回答：以前就有些公司他們就不讓用 std，就是不讓用 RTTI，或者有些根本不是這個領域從業人員但是他們可能有自己擅長的地方。
但是無論哪個行業，他們看中的只是遊戲產業這裡有塊蛋糕，所以 cocos2d 當初不管黑貓白貓反正能抓到老鼠都是好貓的價值觀去誕生的，做商業做生意不是鑽研寫代碼，確實等到你把 Cpp 按照強類型一個個 cast，TDD 把所有的 unit testing 做完保證每一個行為正確性，可能項目已經黃了。
綜合了很多因素，如果從一句【誰是初級程序員，已經明了】去定義這些，確實不太合理，所以我把標題改了，我只能說，cocos2d 充當了商業的炮灰，很多它的用戶也是在公司充當了生產炮灰。
另外，已經有人猜到我用 ST，我用 ECC 你知道不？所以我說吧。。。網上的人不知道提問的人情況，就施加各種評論。

討論過多，無關的一堆東西扯進來沒有意義。
這裡不是討論說誰沒看東西就沒虛心學習啦之類的地方，也不是討論誰寫得辣雞，誰沒經驗的問題（誰把自己說得自己好像多老司機一樣的，這種回復最噁心，你是老司機請解決我的問題，而不是說自己有多高的見識，我有多麼膚淺的見識）。撕逼沒有任何意義，嘴巴上輸了贏了問題沒解決。
項目的 owner 已經回復：
&> 東西是拿來用的，不是拿來看的
項目已老，能用輒用。意見將會以 Pull Request 發，不在這裡回復了。

一開始只是給ios平台搞的遊戲引擎，後來移植到C++跨平台，代碼質量很大程度是歷史原因造成的。

這個團隊顯然把牌打爛了，現在用戶少了也很自然。不過開源項目不就是這樣，你不爽不要用啊，噴也沒用，沒人會動刀大改。

愛過。

作為版本控的我，前兩天還下載了個 3.15 看看。

引擎代碼都是髒的，不髒的都沒多少功能（試試 Atomic，代碼質量不錯），當然 cocos 是髒的更厲害。

不過這一點沒什麼好噴的，這是工程學的本質（霧），介面穩定就行（雖然 cocos 介面也不怎麼穩定）。

然而，真正讓我成為 cocos 黑的原因，並不是因為代碼，而是因為觸控收購了 cocos2d-x 之後，不思進取，不用心提升引擎質量，而專註於營銷，活生生地把本來有希望成為世界最流行國產引擎（算是吧）的一手好牌，打成這樣。

哀其不幸，怒其不爭。

首先這個項目是cocos2d的移植,而cocos2d是用OB-C++開發,所以為了快速移植成C++.所以你能看到代碼中那些不符合C++慣用法的東西.且還有許多其他問題.但是,這個項目的成功99%取決於處在了當時的風口上(移動平台的崛起且當時對於中小型休閒遊戲引擎的需求和市場暫時空白的一段真空期).作者非常聰明的抓住了這個風口霸佔了市場,抓住先機成就了一段市場上的輝煌.雖然時隔多年,代碼一樣爛,一樣不穩定,一樣漏洞百出.被眾多開發者詬病.

如果像你我一樣慢慢咬文嚼字精雕細琢,那等你引擎成型整個市場都變了.這就是實用主義者和"浪漫"型技術人員的區別.Unity的成功也是得以於此.內部代碼混亂不堪,搞出的遊戲內部也是一團亂麻.但能快速出原型,誰上去搗鼓搗鼓都能搞個不三不四又人模狗樣的"遊戲".誰說這不是個成功的產品呢.要知道國內環境就是好這口.工匠精神已不適應這個時代,至少不適應這個賺快錢浮躁的時代.

原歸正題,技術上是不是初級程序員開發不清楚.但至少是一個懂風向有市場眼光的技術人員開發的.

呵呵，樓主還是太年輕了。

引擎是為了解決問題而存在的，不是為了設計優雅而存在的。

我一個autorelease可以大幅降低早期cocos2d-iphone用戶遷移到cocos2d-x的成本，讓cocos2d-x可以快速成長；一個宏強制autorelease可以大量減低大量新手用戶造成內存泄露的可能性從而降低CP的研發成本，這些都是很土很土的——實用主義。這些事情由於我的獨斷專行風格，我從來沒對別人甚至是林順、Ricardo等最親近的人詳細解釋過設計原因，但是 @海洋芝士派好像全看代碼看明白了，厲害。

十幾年前我剛畢業的時候，看了各種設計模式書籍，也是對軟體架構抱有完美主義，直到我進了當年全國銷量最好的『超強糾錯VCD機』項目組，裡面無數很無厘頭的if-else直接把我看暈了。後來我才發現測試組所謂的『超強糾錯』就是把VCD碟片拿去用腳踩在地上摩擦、從研發部所在的三樓扔下去重複10次、從刀劃、用開水燙、反覆摔在地上，然後我就瞬間理解了代碼里無數的if-else，以及為什麼他們能做到國內銷量第一了。

當年這個VCD項目組的老大，現在已經在某香港上市公司負責整個安卓手機的軟體研發了，當年鄰桌的同事已經在微軟西雅圖安逸地coding了，我比較菜只是做出了cocos2d-x而已。順帶一提，當年這個變態測試組的一個主力人員，現在是cocos引擎的測試負責人。所以你在代碼里看到各種奇怪的bug fix代碼也就不足為奇了，這是有歷史淵源的。

我閱讀過很多月流水幾千萬、上億的cocos2d-x遊戲項目源碼，裡面代碼——即使以我的標準——都是真的糟透了，但是並不影響人家成為當年的標杆產品。

所以，樓主你自己先過了這一關，才有可能達到更高的高度。

軟體是拿來用的，不是拿來看的。

不請自來。

作為一個經常黑 cocos 的人, 看到這個問題, 頓時興奮了起來，好久沒有看到撕逼了. 但是你的問題我都沒看完, 我就有預感你要被噴了.

天了嚕, 一個 Hello World 都可以這麼黑 ? 感情這是一個孔乙己呀, 黑了半天就是為了 `茴` 字的三種寫法 ? 為了黑而黑，著實有些低級。

縱觀全局，我們這些用了多年 cocos 粉轉黑的渣渣，黑來黑去無外乎就兩方面：

1. 艱難的 ui 編輯器之路。

2. 版本升級 API 不兼容。

要不就像雲風大佬一樣, 黑 cocos 的粒子系統, 或者像其他野生大牛一樣, 黑 cocos 的文字系統, 渲染系統, 3D 系統.

跳出這些點而黑, 而且還黑的這麼無力, 寶寶可按耐不住要教育你啦. 年輕人, 沉下心來, cocos 並不是任何一個人看了幾行代碼就能黑的, 鑽進去, 找到其真正值得一黑的地方而黑, 能給出解決方案的話最棒啦.

到時候我親自為你點贊.

終於遇到個看起來水平比我還菜的了，我要開始裝逼了。

首先，我不確定題主用的什麼ide，似乎是subline？為什麼不用vs？你所說的報錯，基本上是你自己的問題。任何配置正確的工程，至少可以編譯通過，運行測試工程。

cocos慣例的create函數應該是static node* create (){auto n = new (std::nothrow) node; if (n and n-&>init()){n-&>retain();} return n}

大概就這樣的，用一個宏來定義，我看不出來有什麼問題，我也不清楚，你所說的dynamiccast是用在哪裡的，直接new的對應類，還要轉成什麼？

至於init函數，init函數是cocos框架定義的每個類的初始化函數，就是在create_func里調用的。作為一個派生類，在明確需要先初始化父類的時候，手動調用父類的初始化函數，有問題嗎？這個跟oc的self有一毛錢關係？

你說cocos寫的爛，發展路線混亂，工具做的差，oc痕迹明顯，可以，沒毛病。

但這不是你瞎逼逼的理由。

非常不同意題主的說法，隨便說別人是初級程序員之前，請問你有資格么？拿出你不那麼初級的項目看看？C/C++本身就不限制程序員的手法，何況人家項目都有歷史成因，用C的手法寫CPP可能在某些極端CPP代碼衛道士眼裡不那麼入流，但是我就覺得沒有問題，只要代碼沒有bug，能解決問題，什麼樣的手法是作者的自由，其實很多大公司應用C++也都會保有自己的風格或者子集，因為本身C++也並不強制要求你用什麼風格。以前看過某著名公司的著名和古老的C++項目，最早大概是80年代的代碼，修改至今，為了統一風格就會嚴厲禁止使用模板，不允許用STL等等，完全是C的手法，人家產品行業翹楚，也沒覺得有什麼問題。

這兩天仔細看了一下所有答案

其實如果沒有題主下面一堆話，我相信問題還是一個好問題

但是還是 @海洋芝士派這個朋友，一開始就反對所有人，其實很多人還是站在你這邊的，但是你也反對了。。。不要這重的戾氣

因為看得出來，題主是一個，算是比較年輕的C++，更多的習慣C11的新標準

其實我們仔細來看看cocos2dx這個項目，本人大約是2011年在學校的時候看到這個項目的，當時我也是是從cocos2d-iPhone轉過去的，仔細研究了一下，發現api什麼的都是CC風格和OC很像，很容易就能夠很輕鬆的完成一個遊戲，擼之！

從這裡就可以看出，其實cocos2dx的時間是很長的了

先來看看讓題主噴的幾個環節，無非就是二段構造，宏定義等等，因為我當年也噴過，但是仔細想來有的設計是很好的，比如二段構造，其實減少了很多諸如圖片初始化失敗等等無返回值情況下，減少try-catch的使用，把分配內存與初始化分開，也有利於調試初始化出現的一些問題。

關於宏定義，上面海洋芝士派已經說了。

關於智能指針，其實任何一個老派的C++都會多多少少有一點排斥，因為大家都知道auto_ptr有多坑，在這種情況下，很多人再選擇技術的時候都會或多或少的避開智能指針。

這個引擎的前提是跨平台，支持OpenGL的平台都能用。

arc，當時的手機，並沒有這麼大的內存，要建立一個自動釋放池，android簡直要死，沒有辦法切入後台回收或者再利用，多開幾個遊戲就掛了。其次ARC寫起來也不簡單，如果沒有系統級別的支持，arc 很多實現其實很難。所以你讓一個想要快速搶佔市場的引擎，去自己實現一個arc，恐怕是有點難。

記得曾經一個面試的微軟大神給我說，我用C++幾天或者幾個月寫的內存管理，是無法比C#花了幾年上百人團隊做的內存管理更好的，我深深的牢記了這句話，以至於以後技術選型，我盡量少的選擇了C++，因為內存個管理真的不是一件特別簡單的事情，如果不是大老闆們給大量時間支持，能不碰就不碰吧。

——————————————————————————————————

所以這其實不是一個豆腐渣工程，是一個可以算是不停探索商業化過程的引擎工程，如果當時他必源，做平台等等，進行一切商業化路線，那這個cocos2d可能就不會是現在看到的樣子了，我想正是因為不斷探索商業化過程中，並沒有特別有效的成功，這個引擎現在逐漸定位清晰為一個不算特別大眾，應對與2d遊戲開發的引擎。

同事我們可以看看有什麼地方做的不好？

比如前面朋友說的，粒子引擎等，shader不符合gles spec（我記得曾經在上面實現了一個刀光的shader，怎麼都要崩，後來改用其他方案實現了），多線程渲染也沒有特別好的實現，以及以前獨立一套ui框架等

但是不能因為有一些缺點就已經開噴這是一個豆腐渣工程了，好吧，這也不算是一個老程序對一個產品的態度，

在實際工程項目中，我們一般的設計理念還是先實現功能，至於代碼寫的如何，其實遊戲版本趕進度的時候，並沒有太多關心，反正能實現功能就行，如果遊戲做火了，我們就優化他，如果失敗了，代碼寫的好壞也無關緊要了。

其實可以看出，不管是商業引擎，還是商業項目，決定項目好壞的，往往不是程序員寫的代碼多麼整潔，風格是否統一等等，而是最基本的，能夠如產品策劃設計的一樣跑起來，功能實現沒有問題，等經過市場驗證之後，我們再來慢慢優化項目。

cocos2d作為一個商業引擎也是如此，如果他們拋棄了現有的項目重啟，重新按部就班的一步一步完成功能，做好每一步。那等他出來的時候，也就沒他什麼事了，大家都搞unity去了。

而且我個人認為cocos2d很多代碼還是不錯的，至少當年讓我學習了很多

不是一個優雅的項目

2017-09-09 在前面補充幾句：

在之前回答里，一上來就提到了反對所有人。我承認戾氣很重，是我過激了。在這裡跟大家說聲抱歉。

反省了下為什麼會有這樣的想法，一是因為我錯誤地認為IDE不可能會出現這麼低級的問題，二是題主使用的3.15示例工程和我常用的舊版本不同，所以我先入為主的認為題主修改了代碼從而引發了錯誤。帶著這樣的想法去回答問題，我展現出來的態度的確是不端正的。

不過具體到問題，我絕大部分觀點還是和之前保持一致的。所以答案也不刪改了，留著來警醒自己吧。

---

反對其他所有答案。其他答案中體現出來的各位答主要麼是不了解cocos2dx，要麼是沒有仔細閱讀提問。否則提問中很多問題都是顯而易見的。縱使cocos2dx是有很多問題，但在知乎上隨意潑灑自己的情緒就合適嗎？我覺得答題還是要就事論事，有的放矢。

先說結論：我認為題主以你對Cocos2dx的評價是錯的。而且提問中偏頗之詞、錯漏之處比比皆是，我推測題主對cocos2dx的了解應該在僅僅看了引擎中自帶Helloworld。恐怕題主你才是一位初級程序員吧？

再逐條來說題主的問題：

宏定義一堆，但是都是沒必要的、沒多大用途的，其實可以封裝下的

我不知道題主你cocos的代碼讀了有多少，怎麼說出這麼武端的說出「都是沒必要的、沒多大用途的」這樣的話呢？有的宏確實可以用模板來代替，而且兩者的實現限制、實現效果一致的前提下，應該優先使用模板來實現，這也是很多C++最佳實踐的書籍資料中所提提倡的。但這不意味著所有宏都可以，而題主你說的CREATE_FUNCTION就是其中之一。

要說明CREATE_FUNCTION不適用於用模板替換。先要了解到cocos2dx引擎對象的構建是使用two-stage creation的（歷史原因），對象的創建分為allocate和initialize兩個階段。暫且不具體說這種方式的優劣，因為我們現在也不是要討論設計決策的得失。只需要知道它並不是一無是處的，例如它變相的允許了對象在創建時調用virtual函數。

這又引發了另一個問題，如何保證用戶正確的使用這種對象構建的方式，並且在對象加到autorelease隊列中（這又涉及到cocos自己實現的那套引用計數的問題了，同樣先不評價這個設計）？ cocos2dx選擇的方式是將類的構造函數的訪問限制設為protected的，並且提供了相應的create函數封裝了allocate、initialize和autorelease這個過程，從而就避免了用戶在類的外部去使用new去創建對象，減輕了用戶使用引擎的成本。而宏CREATE_FUNCTION也是提供了這個create封裝的一個默認實現罷了，目的無非是避免寫重複代碼。

那可以使用模板來實現相同目的嗎？在類的構造函數的訪問限制是protected的前提下，要使用模板來創建該類的對象，只有通過友元的方式來實現。相對於友元這種破壞封裝的方式，我認為這裡使用宏來實現是更優雅的方式。才疏學淺，我對C++的了解不深，如果模板有更優雅的方式實現，還請大家指正。

#define CREATE_FUNCTION 是 C 的用例，不是 C++ 的用例
在 C++ 有對象的語言上進行宏替換我也是挺佩服的，而且還要做返回值。

什麼叫「#define CREATE_FUNCTION 是 C 的用例，不是C++的用例」，我不知道題主你對C++的理解有多深，一眾講最佳實踐的書上也沒敢說這麼絕對的話。define的替換語義（我不太懂這是不是改稱作語義）作為C++的一部分，只有說它該不該用的時候，絕對沒有說不能用的，絕對沒有！！而且什麼叫「有對象的語言」，做返回值又有什麼問題呢？

沒考慮過兩者 bridge 會出錯的情況。

這裡壓根就不存在什麼兩者。宏展開之後就是代碼，我不確定題主是怎麼理解的，可以想像出這兩者之間存在的Bridge，想像力還是值得肯定的。題主你貼的圖上，IDE的提示也寫得很明確：

「不能使用一個類型為"HelloWorld*"的右值去初始化類型為『cocos2d::Scene*』的對象」，因為你的HelloWorld*不是cocos2d::Scene*的派生類啊摔！！

可以聯想到開發者本人不清楚自己是在寫 C 還是 CPP，正確用法應該是用 template 抽象。
解決上述問題，加 dynamic_cast，還要非空判斷，不然怕空指針返回了個空 Scene。

不過從這"可以聯想到開發者本人不清楚自己是在寫 C 還是 CPP"，也印證了前面的說的想像力值得肯定。不過題主即使你使用了你說的解決方案，也會一直會返回空值的吧(╯" - ")╯︵ ┻━┻

你確定編譯器、語法 parser 一定能把 CREATE_FUNC 很好地轉換成 static create？

確定的，很確定。可以先和題主賭一個小目標，一個億。

用 C 的思想寫 CPP 本身就是有問題的，用 ObjC 的習慣來寫 CPP 也是有問題的。

這個說法倒是很正確的。

實在無力吐槽，就不浪費時間往後寫了。建議題主你端正態度，要學習，就先要學會放低姿態，不要人云亦云，cocos2dx是有很多問題，但也不是你現有水平可以批判得當的。

2017-09-08補充：

貼上回答中與題主的討論。

我想補充的就是，【你說一堆給初級開發人員聽的】，跟我關係不大。好像誰不會自己寫 RC 一樣的，我倒是正想噴 cocos 幹嘛要自己去生產一套 ARC，A 倒是沒有，只是 RC，為何？你一定不知道 ARC 是編譯時的東西，而不是你手動去寫個 retain。另外，你要保證單例，C++ 單例 Sample 多了去了，簡單的為何不用 static 然後 getInstance。另外，你用過智能指針了沒有？在沒有了解它之前，幹嘛要手寫 RC。無論什麼樣的 RC，都不過是一個對象池，這些是 C++ 項目的通病，因為 C++ 沒有 VM，必須手動管理對象，頻繁的 new delete 系統調用很燒資源降低效率。而且，我的態度很端正，我只是來吐槽一下，如何？

我會講得怎麼細，是為了講清楚，為什麼這裡使用template實現並不優雅。我在回答中同樣講了，對cocos自己實現的這套引用計數先不予評價，自始自終我沒有說過它是一個好的設計。最後，誠然每個人都有評價的權利，但我認為在沒有對一個事物深入了解的情況下，就作出這種全盤否決的評價，這不是一種端正的態度。

2017-09-09

下面貼的圖是錯的，是3.10版本的空白工程，抱歉。

題主在評論中回復我關於所所用的cocos版本：

我用的是 3.15.1 版本的

特意下載了這個版本並按題主說的用命令cocos new -l cpp創建了項目。但是我的~~

Scene* HelloWorld::createScene()函數定義如下：

請問題主你確定你沒有修改過嗎？

還有，你居然一開始就否決其它所有答案，然後說我全盤否決。。。其實有些答案比如
@王津
說的，通過回復和討論，其實我認為也是合理的，因為項目多多少少存在迭代問題，我覺得這個不要緊，我只是【建議】跟上時代，然後能不能讓我 IDE 多點友好提示，少點 Error Warning 而已。

按題主開始問題的說法「cocos2d-x 是初級程序員開發的項目嗎？」到後來的「cocos2d-x 是豆腐渣項目嗎？」，如果這不叫全盤否決什麼叫全盤否決？否決我回答之前的所以的答案理由我在題目中也說了，不在這裡重複了，我依舊堅持我當時的觀點。而且我不覺得cocos有什麼沒跟上時代的，主流平台的主流IDE，Visual Studio、XCode、Android Studio都支持，這才是叫主流的IDE，你用的ST+ECC並不是。當然我只是建議【建議】你跟上時代。

至於題主在提問補充中提到的其他問題，在評論中提到的其他問題。我並不是說避而不談，只是時間精力有限，一一展開需要說得太久太多。

噢對了，你居然把 Xcode 列入Cpp 主流開發平台（以cocos2d-x cpp為依據），我覺得你是把 Jetbrains CLion遺忘了，Xcode 對 cpp支持很弱，重構都不支持，利用它的 iPhone SDK 來打包還不錯，你沒在 mac 上做過 cpp 開發吧？

把XCode列入主流IDE，不是依據於它與其他IDE對C++的支持相對強或弱，是根據使用它的用戶多少。有個前提是我們討論是一個主打移動平台的、主要開發語言為C++遊戲引擎，在macOS下用戶更多的必定是XCode。如果這都想不明白的話，呃，要不再想想吧。

你所遇見、認知世界是有限的，請不要努力用你有限的世界去證明別人的世界都是錯的。不要說些什麼避而不談什麼的去自以為自己很強大啥都能解釋，我不需要聽解釋，每個用戶都有他們特定的平台環境，你是解釋不完的。作為回答問題的人，請找解決方案，而不是批評指責更不是說一堆無關緊要的解釋。

那些都不是解釋呀，我那些是在反駁你。所以說得比較詳細，是這裡討論到的問題是有前提的，如果我上來就說，這個地方我認為就該用宏，不該用模板，你能接受嗎？但是你看就算是這樣，你好像也沒有接受多少啊。會專門說沒有避而不談，是擔心你會不會覺得我對你的話選擇性的忽略罷了。

在上面貼出的Helloworld的工程版本有錯，是3.10的，是我的疏忽，向題主說聲抱歉，這確實就是cocos創建出來的空白工程。

沒法用就不要用啊。

cocos2dx曾經火過，但是現在明顯已經過氣了。無論cocoscreater還是其他什麼改變都只是續命而已。不是遺留項目為什麼還要用它呢？更何況還是c++版本。

曾經做手游用cocos是正確的技術選型，而現在用它就是錯誤的技術選型。當然遺留項目屬於歷史原因，無所謂對錯，只能接受。

一個技術之所以火起來是因為它在合適的時間出現，解決了合適的問題。並不是因為它代碼多麼優雅，架構多麼合理，技術多麼牛x。

雖然不是很好，但還不至於到豆腐渣的程度。要不然不會那麼多人用。

平時加班嚴重，今天周日，剛好有時間表達一下內心的感受。用cocos2d有四年了，剛開始用的時候，把cocos當成一個神話來使用，沒有任何bug的存在，做遊戲過程中出現的任何問題，都是歸根於是遊戲項目設計的問題。找bug都是從遊戲項目中開始，在從遊戲項目中解決。當時只是一個新手，覺得引擎太強大，有很多設計非常優秀，值得我去學習。於是學習裡面設計模式，學習一個大的項目的架構。學習一下c++使用方式。不僅當時崇拜引擎的曠世之作，到現在也崇拜，儘管隨著使用的時間越長，發現的問題也隨之增多，因為這些問題，都是在我可控範圍之內，改一兩行代碼或者新增幾行代碼就能搞定。總而言之雖然有些問題，都是小改動。並且有些問題，我覺得是遊戲項目本身的功能需求出現的。這個可以理解，自己加上引擎沒有實現的功能就好了，引擎團隊也不知道使用的引擎的人要開發發什麼樣遊戲。只能盡量滿足大家的需求，我覺得在這點上引擎做的已經很好了。之前遇到的bug，都是小bug，我覺得遊戲開發者肯定可以搞定。目前在使用cocos2dx 3.13做項目，項目比較特殊，做成大廳式的遊戲。遊戲中包含很多遊戲。這些遊戲不是本公司的開發的，使用的引擎版本都不同，有的js 有的lua 有的c++. 有的2.2版本有的3.1版本，有的3.9版本，需要把這些集成在一個遊戲中，做成一個app，做這件事之前，以為會很簡單，但真正做起來，任務量和難度都是有點大的。當然做這個對引擎有了更近一步的了解，發現了很多內泄漏。單利釋放那塊。 director 重啟那塊。 js層面閉包創建的cocos對象沒法釋放等。 helloworld工程，basedata help...什麼的內存泄漏，有1位元組的內存泄漏，這個泄漏查明是 Ref類中 push到list中的原因， list用來查看飲用技術中還沒有釋放的對象。本人使用的xcode開發，有些全局的 Ref子類對象，會在main函數之前調用。 main啟動的時候那個list里的元素會清空，很蛋疼。還有不要在getinstance 里加 static 實力變數，銷毀單利釋放的會出現。之前沒覺得問題，因為只是獲取實例，但是現在的需求需要釋放大部分引擎對象，方便進入下一個遊戲。泄漏的問題被我解決的差不多了，有些泄漏，沒法解決，用leak工具只看到紅色的方塊，沒有對應的堆棧，很蛋疼。。總之，引擎雖然不是很完美，但是已經很可以，畢竟引擎是要滿足大眾的需求，而不是少量的開發者的需求，自己改一改就好了。

「成果比語言有力」——雅洛藍-霍芬伯格-海瑟薇

你可以寫一個更強更牛逼的引擎

然後碾壓這個「辣雞引擎」

就醬

你們都從這麼高的高度看cocos2d-x，我還在努力的看源碼。。有一些看不懂啊。。使勁看啊。。。

不是豆腐渣工程！

但是極具中國特色，好大喜空，要大要全，2d,3d,vr，h5都要插一插，很多形象工程，自己的優勢不能發揮到最大，不要迭代改革，動不動就革命推出全新世界，很遺憾

cocos2dx的唯一缺點是沒有像U3D那樣的編輯器和開發流程，開發遊戲能達到目的就行了，哪裡需要管那麼多底層設計和優雅代碼？你以為你再搞阿波羅飛船的編程？

我要能搞出個cocos2d x，我感覺我就此生無憾了。什麼豆腐渣不豆腐渣的。當然，這想法在大牛眼裡肯定是太不思進取了，匿了。

作為從2.1.3版本都一直在用的我，也開發了款2d單機網遊。其實覺得cocos2dx還不錯啊！

首先他們解決我們的問題，能根據需求開發出想要的遊戲，性能等也都不錯。唯一麻煩的是害怕升級，每次升級介面變化太多，移植太麻煩。

再說他的設計，我覺得不用完全沒必要糾結細節，也許完成一個功能有N種寫法，那麼簡單最重要，畢竟代碼是給人看的。

總之能解決你的問題最重要！現在js,lua,c++全支持，用js開發的話全平台適配，為了快速出應用還是很不錯。

編譯MSVC的cocos2d-x一堆未定義變數和奇奇怪怪的報錯，但是卻不影響運行，當初剛接觸的時候也是感覺一股怪怪的感覺

看大神們撕得很厲害啊。

斷斷續續寫了3～4年cocos，現在在轉u3d的路上。

看你如此推崇cpp的一些特性，就知道你沒啥實際項目經驗。

題主完全可以把這些話發到issue里去，再發個PR針對以上所述問題一一解決，開源項目就是這樣，你不喜歡可以不用，而且，人家開發者也不上知乎。

Talk is cheap.