Гарантированное удаление объекта - Страница 4

carrotoff · 01.05.2011, 14:28

ShadowsInRain, непонятно чего вы хотели добиться, открывая этот топик. Совета?.. хм.. вряд ли, пост каждого отвечающего был оспорен вами.

mikhailk · 01.05.2011, 16:27

Цитата:

Да ладно? Ну и как же однозначно удалить объект средствами языка?

Простой объект - отписать от событий, удалить из дисплейлиста, занулить ссылки на него, присвоить ему самому null и ждать GC.

Сложный объект (например, собранный из нескольких мувиклипов и битмапов, загруженных из внешних библиотек/файлов) - нужно конкретно смотреть, что за зверь. Но за редким исключением правило одно - разборка производится в порядке, обратном сборке. Кое-что из памяти удалить невозможно, это тоже надо учитывать.

Есть, кстати, еще способ. Наблюдаю у многих игростроителей. Забить на утечку памяти.

Цитата:

У меня нет выбора — начать с простого, или сразу взяться за сложное. У меня есть выбор — решить задачу средствами флеш и АС3, или вернутся к нативному решению на С++

Это возможно только в том случае, если речь идет о десктопном AIR-приложении. Не уверен, что нужно писать десктопные игры таким образом.

Котяра · 01.05.2011, 18:15

Ещё один способ: реиспользование объектов.
Плюсы - нет необходимости полностью удалять, что положительно сказывается на производительности.

expl · 01.05.2011, 18:42

но перед тем, как вернуть объект в пул dispose() - методы тоже надо вызвать, чтобы отписывать от всего внешнего и все таймеры остановить (разве что при этом bitmap-даты диспозить не надо - иначе выигрыша не будет)
Т.е. все равно надо знать время, когда объект боле не нужен.
Т.е. это способ оптимизации, но никак не способ упрощения очистки памяти и "замораживания" неиспользуемых объектов.

ShadowsInRain · 03.05.2011, 13:50

Цитата:

Сообщение от КорДум

ShadowsInRain, покажите лучше Ромеро и Кармаку вот эту ссылку: http://ru.wikipedia.org/wiki/Инкапсу...ограммирование)
Так реализовывается правильная фабрика. Или даже не так: фабрика вообще.

Я не знаю, в какой раскладке надо набирать "фабрика" в гугле, чтобы получить ссылку на инкапсуляцию. :]
Вот фабрика, о которой идёт речь:
http://ru.wikipedia.org/wiki/Абстрак...проектирования)
http://ru.wikipedia.org/wiki/Фабричн...проектирования)

Цитата:

Сообщение от mikhailk

Простой объект - отписать от событий, удалить из дисплейлиста, занулить ссылки на него, присвоить ему самому null и ждать GC.

Зануление сссылок потребует написания ещё одного класса, причём ссылки будут зануляться даже тогда, когда они никому не понадобятся. А если писать метод, получающий временную ссылку из псевдо-ссылки (из интегрального uint, с ним точно отличишь временную от постоянной), то оверхеды сойдут к минимуму, реализовать будет проще, и не будет казусов а-ля "забыл проверить ссылку на нуль", потому что постоянная валидация просто не даст ошибиться.

Цитата:

Сообщение от mikhailk

Это возможно только в том случае, если речь идет о десктопном AIR-приложении. Не уверен, что нужно писать десктопные игры таким образом.

Во-первых, альтернативный вариант — написать на С++, я об этом уже много раз говорил. при чём тут АИР, я не вкурил. Во-вторых, у меня нет цели написать именно десктопное приложение, иначе бы я не брался за флеш. Флеш привлекает меня тем, что впоследствие игру можно будет раскидать по социалкам и тематическим сайтам. ЧСХ, нативные игры распространять гораздо сложнее.

Цитата:

Сообщение от Котяра

Ещё один способ: реиспользование объектов.
Плюсы - нет необходимости полностью удалять, что положительно сказывается на производительности.

Паттерн "пул объектов". Да, в некоторых случаях это хорошая вещь. Но в моей ситуации она чревата 100% багами (мобы будут разговаривать с трупами или воздухом, например, или попытаются попасть за пределы карты, и т.д.) или опять-же придётся делать постоянные проверки, которые проще релизить в виде однозначного удаления.

Кстати, спасибо всем за дискуссию. Так или иначе я прокрутил в голове или даже опробовал предложенные варианты. Пришлось засучить рукава и нахмурить брови, но работа идёт. Остановился на косвенной фабрике объектов. Поясняю. Все объекты создаются нормальным способом, но требуют указать менеджера, к которому они будут привязаны. Ссылку на объект можно хранить только временно, в остальном у объектов есть свойство handle, та самая псевдо-ссылка (или слабая ссылка). Менеджер управляет самыми общими свойствами, в т.ч. вызывает виртуальные функции, вроде тестов на коллизию (он занимается физикой, помимо всего), и занимается удалением объектов и проверкой слабых ссылок (сделал их в виде uint). В общем, всё, что нужно для первичного взаимодействия, есть у менеджера. Всё остальное реализуют конкретные классы, и тут уже в работу вступают операторы Is и As. В будущем можно запилить рассылку сообщений от имени менеджера для разных и интересных вещей.

UPD
Ещё немного, если кому интересно. Псевдо-ссылка (хендл) содержит в себе индекс объекта в контейнере Vector. Чтобы обеспечить плотность контейнера и чтобы он со временем не разрастался до бесконечности, освободившиеся слоты занимают другие хендлы. А чтобы было понятно, ведёт хендл на старый объект или его слот уже кто-то занял, хендл поделен на две части. В младшем слове (dword, short, 16 бит) хранится индекс, а в старшем - ключ, который генерируется заново при повторном использовании слота.

КорДум · 03.05.2011, 14:30

ShadowsInRain, инкапсуляция предоставляет интерфейс взаимодействия. Вот по вашей второй ссылке на фабрику как раз видно, что взаимодействие осуществляется через интерфейсы. Иначе в фабрике нет смысла (извините, но это быдлокод, когда все обо всех всё знают).

ShadowsInRain · 03.05.2011, 15:32

КорДум, ну дак я и пишу, что все обо всех знают не всё, а только то, что нужно для взаимодействия. Все объекты внутри мира друг друга видят, как объекты базового класса (у меня он называется Actor), а дальше уже дело техники — виртуальные функции и полиморфизм.

mikhailk · 03.05.2011, 16:49

Цитата:

Во-первых, альтернативный вариант — написать на С++, я об этом уже много раз говорил. при чём тут АИР, я не вкурил. Во-вторых, у меня нет цели написать именно десктопное приложение, иначе бы я не брался за флеш. Флеш привлекает меня тем, что впоследствие игру можно будет раскидать по социалкам и тематическим сайтам. ЧСХ, нативные игры распространять гораздо сложнее.

Сорри за мою тупость, но как Вы планируете игрушку, написанную на С++ запускать под браузерами?

ShadowsInRain · 03.05.2011, 16:55

Цитата:

Сообщение от mikhailk

Сорри за мою тупость, но как Вы планируете игрушку, написанную на С++ запускать под браузерами?

Никак. Потому что не собираюсь. /_o

mikhailk · 03.05.2011, 17:49

А при чем тут тогда flash/AS3?

Кстати, по поводу AIR - я видел десктопные игры на AS3/AIR. Теоретически, они могут быть портированы в браузерки для соц.сетей. Но практической реализации два-в-одном я не видел.