Как уничтожить экземпляр класса (объект)?

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

https://www.youtube.com/watch?... e=youtu.be

1

Сообщение от Fulcrum_013 Вот тут вам пример графа. C# vs Kotlin Это без инстаного разрушения инстансов при разрыве ссылок работать не будет в принципе.

Не будет. А причем тут Dispose?

Сообщение от Fulcrum_013 Такое что Dispose - костыль предназначенный для ручной реализации именно такого поведения.

Как с помощью Dispose вручную реализовать именно такое поведение?

Сообщение от Fulcrum_013 Сборщик не в состоянии обрабатывать слабые ссылки вовремя.

Вкурсе вообще как часто и при каких обстоятельствах запускается GC?

0

Сообщение от nicolas2008 Вкурсе вообще как часто и при каких обстоятельствах запускается GC?

Как написано у мелкомягких - переодически. Обычно когда предвыделенный буфер памяти закончился перед отгрызанием новых страниц у оси. Т.е. в принципе может и вооще никогда не запустится. Но главное что он в любом случае запускается отложенно. Что абсолютно неприемлимо для управления жизненным циклом инстансов/ресурсов.

Добавлено через 3 минуты

Сообщение от nicolas2008 Как с помощью Dispose вручную реализовать именно такое поведение?

А при чем тут вообще уничтожение самого буфера то? Это и ежу понятно что у плюсов куча а у шарпа эмулятор стека с компрессией и работают они по разному. Вопрос не о буферах а о живущих в них инстансах. А когда сами буфера уничтожаются и уничтожаются ли они вообще или память реально бесконечная для обеспечения корректности поведения инстансов вообще фиолетово.

Добавлено через 1 минуту

Сообщение от nicolas2008 Не будет. А причем тут Dispose?

При том что он предназначен для ручного осуществления инстантного разрушения инстанса раз уж автоматика для этого негодная. Точная копия паскалевского деструктора.

0

Сообщение от Fulcrum_013 Но главное что он в любом случае запускается отложенно. Что абсолютно неприемлимо для управления жизненным циклом инстансов/ресурсов.

А я вот считаю что GC с его отложенным запуском вполне справляется с управлением жизненным циклом инстансов/ресурсов, докажите мне обратное раз вы утверждаете что отложенный запуск GC для этого неприемлем.

У меня вот за много лет пока не возникло такой ситуации, где GC бы не справился...

0

Someone007, Уже показывали очень распространенную ситуацию в которой он не применим в принципе.

Добавлено через 3 минуты

Сообщение от Someone007 я вот считаю что GC с его отложенным запуском вполне справляется с управлением жизненным циклом инстансов/ресурсов

Да можете считать что угодно. Но лучше таки читать то что по этому поводу пишут произвозводители в инструкции к оному GC . А пишут они что программа не должна рассчитывать на то что финализаторы будут когда либо вызваны автоматически.

Добавлено через 8 минут
Someone007, А еще лучше понимать принцип работы алгоритма сканера объектов и, в результате, понимать почему они это пишут, и точно знать почему в инструкции к GC никогда что то другое написано не будет.

Добавлено через 26 минут

Сообщение от Someone007 У меня вот за много лет пока не возникло такой ситуации, где GC бы не справился...

Очень странно. Я его в ситуацию где он не справился на первой же лабораторке по Симула-67 загнал. Тогда собственно и разобрался досканально почему этот анахронизм из всех профессиональных языков выбросили еще в начале 80-х.
Вы наверное кроме CURD под винформз/wpf ничем его не озадачивали? Так там к корректному поведению фреймверка GC вообще не при чем. Под капотом ручной разрыв взаимосвязей путем вызова Dispose на каждом шагу один в один с дельфой. Потому при пользовании фреймверком это и не сильно заметно пока только CURD гоняешь точно так же как в дельфе. А вот когда дело доходит до расширения фреймверка или сложных иерархий объектов для моделирования чего либо вот тут и начинаются опаньки и сразу очень хорошо видно что от полного ручника паскалевского разлива наличие GC ничем не отличается кроме бесполезного оверхеда. Кстати причина по которой винформз настолько куцей по сравнению с дельфой получилась.

0

Сообщение от Fulcrum_013 Уже показывали очень распространенную ситуацию в которой он не применим в принципе.

Вы ничего не показали. Всё, что вы показывали было опровергнуто.

0

Usaga Идите учите доку. А то даже не можете понять что пытаетесь в качестве опровержений пихать подтверждения. НУ не работает оно без вызова Dispose как надо. А как его вызывают - с using или без - это к пригодности GC отношения не имеет. ТАк что еще раз - вытатуируйте у себя на лбу слово быдлокодер раз даже мануал понять не в состоянии.

0

Fulcrum_013, я вам код выше приводил, где было чётко видно, что Dispose() ничего не уничтожает и в процессе сборки мусора не участвует. Или вы хотите сказать, что объекты классов без метода Dispose() вообще не убираются?

Приведите цитату из "доки", где говорится о том, что Dispose() уничтожает инстанс. Напомню вам вашу фразу:

Сообщение от Fulcrum_013 Поэтому если нужно принудительно разрушить объект то пишите для этого специальный метод который высвобождает ресурсы и т.д.(по конвенции он называется Dispose) и вызываете его ручками.

Будьте добры показать как с помощью Dispose можно принудительно разрушить объект. Докажите пожалуйста, что вы не ботало.

1

Сообщение от Usaga Будьте добры показать как с помощью Dispose можно принудительно разрушить объект.

Точно так же как он уничтожается при помощи деструктора. Не понимаете о чем речь - идите учите матчасть.

0

Fulcrum_013, сам по себе деструктор не удаляет обьект. Он только описывает дополнительные шаги которые необходимо выполнить при удалении обьекта.

Добавлено через 7 минут

Сообщение от Fulcrum_013 А при чем тут вообще уничтожение самого буфера то? Это и ежу понятно что у плюсов куча а у шарпа эмулятор стека с компрессией и работают они по разному. Вопрос не о буферах а о живущих в них инстансах. А когда сами буфера уничтожаются и уничтожаются ли они вообще или память реально бесконечная для обеспечения корректности поведения инстансов вообще фиолетово.

Удаление обьекта - это освобождения памяти.
Откуда эта ересь о "эмуляторе стека с компрессией"?

0

Сообщение от nicolas2008 Он только описывает дополнительные шаги которые необходимо выполнить при удалении обьекта.

Он разрушает инстанс (объект в терминах ООП). А это абсолютно не тоже самое что объект в терминах GC (банальный кусок памяти).

Добавлено через 5 минут

Сообщение от nicolas2008 Откуда эта ересь о "эмуляторе стека с компрессией"?

Из назначения GC. Он проектировался для того чтобы держать в аппаратном стеке только адреса возвратов, а стек данных на внешнем накопителе (перфолентеленте, позже магнитной ленте). При этом для перфоленты абсолютно необходимо переодически переписывать на новую ленту актуальные данные, а для магнитной ленты такая же дефрагментация снижает потребную перемотку . А вы думаете этот анахронизм еще для чего то годен? Для памяти с призвольным доступом а тем более при ее страничной организации дефрагментация полный нонсенс. А для какая либо годная для ООП автоматика у GC отсутствует от слова совсем. При этом неумение размещать промежуточные данные на аппаратном стеке выходит большим боком исключающим многопоточность.

0

Сообщение от Fulcrum_013 Он разрушает инстанс (объект в терминах ООП). А это абсолютно не тоже самое что объект в терминах GC (банальный кусок памяти).

Ничего он не разрушает. Он запускает освобождение памяти для обьектов которыми владеет.

Сообщение от Fulcrum_013 Из назначения GC. Он проектировался для того чтобы держать в аппаратном стеке только адреса возвратов, а стек данных на внешнем накопителе (перфолентеленте, позже магнитной ленте). При этом для перфоленты абсолютно необходимо переодически переписывать на новую ленту актуальные данные, а для магнитной ленты такая же дефрагментация снижает потребную перемотку .

Я не знаю что там у вас за анахронизмы в голове. Может не анахронизмы, а просто каша.
Вы хоть одну книгу о .NET прочитали? Или все ваши познания об организации памяти основаны на каких то флешбеках из прошлого? Или просто фантазии?

Сообщение от Fulcrum_013 Для памяти с призвольным доступом а тем более при ее страничной организации дефрагментация полный нонсенс.

А как же массивы которые требуют выделения неразрывного участка памяти?

Сообщение от Fulcrum_013 При этом неумение размещать промежуточные данные на аппаратном стеке выходит большим боком исключающим многопоточность.

Либо вы подтверждаете свои бредовые изречения авторитетными источниками, либо разговор окончен.

0

Судя по заваленным тестам С#, человек вообще не отдупляет что такое C# и с чем его едят.

0

Сообщение от nicolas2008 Либо вы подтверждаете свои бредовые изречения авторитетными источниками, либо разговор окончен.

Единственный источник который может быть авторитетным - математический анализ алгоритма. Наука к вашему сведению авторитетов не признает.

Добавлено через 2 минуты

Сообщение от nicolas2008 А как же массивы которые требуют выделения неразрывного участка памяти?

Вот страничная организация памяти этот вопрос и решает. Выбираются полностью пустые страницы и перемапируются в конец адресного пространства. Что на кучу порядков быстрее чем постоянные дефрагментации. При этом активный дефрагментатор в любом случае сливает пассивному нефрагментатору а тем более субкучам и управлению на основе регионов.

0

Сообщение от Fulcrum_013 Единственный источник который может быть авторитетным - математический анализ алгоритма. Наука к вашему сведению авторитетов не признает.

Понял. Значит разговор окончен.

0

Сообщение от nicolas2008 Вы хоть одну книгу о .NET прочитали?

А что алгоритм сканера GC с 59-го года мог как то изменился? Только получил некоторые оптимизации да и то они чаще пессимизации чем оптимизации. Но как не оптимизируй в принципе непригодный к управлению жизненным циклом алгоритм пригодным он от этого не станет.

Добавлено через 4 минуты

Сообщение от nicolas2008 Он запускает освобождение памяти для обьектов которыми владеет.

Вообще то память высвобождает ТОЛЬКО GC в языках с GC или специальная функция в языках без оного. А деструктор точно так же как и Dispose производит логическое разрушение экземпляра класса - т.е. отвязку его от модели данных, и высвобождение владемых ресурсов. После этого объект для модели считается несуществующим и его буфер безопасно переиспользовать.

0

Сообщение от Fulcrum_013 Точно так же как он уничтожается при помощи деструктора. Не понимаете о чем речь - идите учите матчасть.

Покажите пример кодом, где Dispose() уничтожает объект. Докажите, что вы не трепло (вангую: не докажите).

0

Сообщение от Usaga Покажите пример кодом, где Dispose() уничтожает объект.

ну для примеру вот так
Один в один с деструктором в паскале. Т.е. высвобождение ресурсов и т.д. манипуляции приводящие объект в состояние в котором переиспользование его буфера безопасно. Т.е. перезапись буфера другими данными не приведет ни к каким утечкам в т.ч. ресурсов, висячкам и т.д. в зависимости от назначения класса и его места в иерархии.

0

Fulcrum_013, а уничтожение самого объекта где?

0

Сообщение от Usaga а уничтожение самого объекта где?

А вот это оно и есть. После этого телодвижения то что осталось в буфере объектом (сущностью предметной области) уже не является. А соответсвенно безопасно переписать буфер другими данными.

0

Fulcrum_013, вы просто декриптор окна закрыли. Где уничтожение самого объекта Foo?

0