В чем преимущества модели памяти Cocos2d-x?

Question

Как я недавно начал развиваться в Cocos2d, одной из первых особенностей, которые я нашел очень своеобразной, была модель памяти пула Autorelease Objective-C. Во всем моем опыте работы с C++ я избегал использования любой формы распределения динамической памяти, если АБСОЛЮТНО не требуется (что на самом деле очень редко).

Сначала я был озадачен, почему Cocos2D не воспользовались более безопасных альтернатив для создания объектов указателей (например, смарт-указатели), но потом я наткнулся на this нить, на которой обсуждались недостатки shared_ptr<class T> (наиболее значительные из которая была скоростью) по текущей парадигме памяти в отношении ручных методов сохранения/освобождения.

Тогда я подумал: «Почему бы просто не выделить объект регулярно и передать и сохранить его ссылку, когда это необходимо?» Я понимаю, что было бы очень трудоемкой переносить всю систему памяти Cocos2d-x на новую парадигму, но в долгосрочной перспективе не стоит ли использовать более стабильный идиоматический код на C++?

В чем все дело доходит до того, каковы преимущества текущей модели памяти в отличие от обычного распределения объектов?

Answer 1

Управление памятью в игровых машинах - это очень конкретная тема, особенно если вы хотите, чтобы ваш движок был простым в использовании. Если вы взглянете на Unreal Engine 4, они значительно продвинулись в своем подходе к управлению памятью, создав код отражения. Вообще говоря, можно создать игру cocos2d-x без явного вызова retain или release. Эти методы в первую очередь используются, когда вам нужно вручную продлить время жизни объекта, чтобы избежать его удаления и создания его снова (кэширование).

Общие указатели сделают синтаксис более сложным и вызовут дополнительные трудности с динамическими нажатиями и указателями привязки в качестве аргументов. И что более важно, вам придется использовать weak_ptr вместе с общим, чтобы избежать перекрестных ссылок, которые также потребуют дополнительных усилий.

В принципе shared_ptr - эталонный метод подсчета, такой как intrusive_ptr, который может быть более естественным образом интегрирован в cocos2d-x. А функции, подобные addChild/removeChild в кокосах, увеличивают и уменьшают счетчик дочернего объекта, поэтому эти парадигмы не так разнообразны, как может показаться на первый взгляд.

Answer 2

Я не считаю, что Cocos2d-x управляет Ref производными объектами с использованием парадигмы Objective-C по любой технической причине. Смарт-указатели C++ (или «регулярное размещение объектов»), вероятно, будут работать так же хорошо, если не лучше.

Однако, исторически Cocos2d-x является C++-портом проекта Cocos2d, который был родным Objective-C (который был, iirc, портом более раннего игрового движка на основе Python). Таким образом, использование методов AutoReleasePool и «сохранить» и «выпуска» является историческим.

Изменение его теперь сломало бы много кода и раздражало бы множество разработчиков и с какой целью? Немного более идиоматическое использование C++ stl?

Важно то, что управление Ref объектов легко, возможно, намного проще, чем пытаться научить разработчиков, чтобы обернуть вещи в правильной * _ptr <> и позволяет Cocos2d-х проект - скрыв большую часть управление памятью - для поддержания паритета характеристик с помощью Cocos2d-js. (Я думаю, что есть также попытка сохранить совместимость с Cocos2d).