Cocos2d-xカスタムメモリモデルの利点は何ですか？

Question

私が最近Cocos2dで開発を始めたとき、私が非常に独特だった最初の機能の1つは、Objective-Cスタイルの自動解放プールメモリモデルでした。 C++での私の経験では、絶対に必要でない限り、どのような形式の動的メモリ割り当ても使用することは避けました（実際は非常にまれです）。

まず、私はCocos2Dが（例えば、スマートポインタ）ポインタオブジェクトを作成するためのより安全な代替を利用しなかった理由として当惑したが、その後、私はshared_ptr<class T>（の最も重要なの欠点を議論しthisスレッド、出くわしましたこれは手動の保持/解除方法に関して現在のメモリパラダイムよりも速かった。

私は「オブジェクトを定期的に割り当てて、必要に応じて参照を渡し保存するのはなぜですか？私は、Cocos2d-xのメモリシステム全体を新しいパラダイムに移植するのは非常に時間がかかることを理解していますが、長期的にはより安定したイディオムのC++コードを使用する価値はありませんか？

通常のオブジェクト割り当てとは異なり、現在のメモリモデルのメリットは何ですか？

Answer 1

ゲームエンジンでのメモリ管理は非常に具体的なトピックです。特にエンジンを使いやすくしたい場合は、 Unreal Engine 4を見てみると、リフレクションコードを生成してメモリ管理のアプローチをさらに進めています。一般に、retainまたはreleaseを明示的に呼び出すことなく、cocos2d-xゲームを作成することは可能です。これらのメソッドは、まずオブジェクトのライフタイムを手動で延長して削除しないようにする必要がある場合に使用され、再度作成（キャッシング）されます。

共有ポインタは構文をはるかに複雑にし、動的キャストとバインディングポインタを引数として追加の問題を引き起こします。さらに重要なことは、相互参照を避けるためにweak_ptrを共有と一緒に使用しなければならなくなり、余分な労力がかかります。

基本的にshared_ptrは、より自然にcocos2d-xに統合できるintrusive_ptrのような参照カウント手法です。そして、ココスのaddChild/removeChildのような関数は、子オブジェクトのカウンタを増減しているので、これらのパラダイムは最初の一見で見えるほど多様ではありません。

Answer 2

私はCocos2d-xが技術的な理由でObjective-Cパラダイムを使用してRef派生オブジェクトを管理しているとは思わない。 C++のスマートポインタ（または「通常のオブジェクトの割り当て」）は、おそらく同様にうまく機能しません。

歴史的に、Cocos2d-xはCocos2dプロジェクトのC++ポートです。これはネイティブのObjective-C（これは以前のPythonベースのゲームエンジンのポートです）でした。したがって、AutoReleasePoolと 'retain'メソッドと 'release'メソッドの使用は歴史的です。

これを変更すると、多くのコードが破損し、多くの開発者が迷惑をかけ、何が終了するのでしょうか？ C++ stlのやや慣用的な使用ですか？

重要なことは、Refオブジェクトの管理が容易であること、正しい* _ptr <で物事をラップするために、開発者を教えようよりも間違いなく多くの方が簡単である>、およびCocos2d-xのプロジェクトを可能にする - のほとんどを隠すことにより、メモリ管理 - Cocos2d-jsとの機能パリティを維持します。 （私はCocos2dとのAPI互換性を保つ試みもあると思う）。