Лики памяти (общее)

[wvxvw]

Деструкторы в (о, а это как перевести?) managed среде не нужны, да и не возможны. Вам среда не сообщает, да и не должна, и не будет никогда сообщать о том, когда объект удаляется. Это делается специально для вашего же блага, чтобы вы могли писать код типа foo(bar()) не заботясь о том, что ссылка на результат bar() потерялась, и ее теперь никак не удалить.
Правельно - просто не хранить ненужные данные, т.е. удалять их как только они перестали быть нужны, и тогда все логично встанет на свои места.

[in4core]

mayakwd как привел сссылку - мне понравилась идея, что от мышиных событий типа клика и овера например отписываться не обязательно. Так ли это?

[dimarik]

В первом посте имеет место быть бессмысленная операция удаления обработчика из собственного списка обработчиков. Удаления собственного слушателя может быть целесообразным только в одном случае — обработчик хранится в стороннем объекте, не подлежащему удалению.

[silin]

это чего-то ты непонятное сказал, как то есть бессмысленная ?
объект, подписавший на ENTER_FRAME свой метод, будет исправно получать в него событие до второго пришествия срабатывания GC, почему бы не отписываться-то от него
другое дело, если события в принципе не будут генериться (мышиные дела например), то и путь бы с ними

[etc]

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

В первом посте имеет место быть бессмысленная операция удаления обработчика из собственного списка обработчиков. Удаления собственного слушателя может быть целесообразным только в одном случае — обработчик хранится в стороннем объекте, не подлежащему удалению.

И если это броадкаст событие.

[dimarik]

Согласен, есть категория событий, от которых необходимо отписаться когда надобность в их получении пропадает.

Только эти действия к утечкам памяти не имеют никакого отношения.

[silin]

>>Только эти действия к утечкам памяти не имеют никакого отношения
частично имеют: сами события тоже висят в памяти пока их не подберет GC, это как бы не утечка, рано или поздно почистится, но все же