Ок. Удаление объектов в .NET....
Из С++ : удаление будет произведено сразу же после выхода объекта из области видимости путем вызова дестрокутора и освобждении памяти...
В .NET же удаление сразу нет (ну оно понятно почему)... при выходе из области видимости уменьшается количество ссылок на объект, потом (неизветно когда) пробегает 1-2 раза GC по памяти и чистит (попутно сжимая кучу) память..и вызывая деструкторы (финализаторы aS .NET like) и Dispose() (ежели IDisposable вообще реализуется)....я правильно понимаю картинку)?
ежели правильно то почему финализатор вызывается из GC, а не при достижении внутреннего счетчика ссылок нуля? Тогда необходимость в Dispose() вообще бы отпала (?). Необязательно сжимать кучу, достаточно вызова деструктора и помечании объекта как готового к уничтожению из памяти... почему сделано иначе ?!
Никак не могу найти разумного объяснения (.... в общем хочу узнать почему 8) не пинайте строго.. я сам "из мира другого" (c++)))

Это сообщение отредактировал(а) jonie - 19.8.2007, 21:08

Потому что нет никакого счётчика ссылок.

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

GC проходит по куче, и освобождает память путём удаления объектов, на которые не имеется ссылок. После этого дефрагментирует кучу. Вопрос: зачем освобождать память и дефрагметировать кучу каждый раз после того, как объект "вышел из поля видимости" и на него не имеется указателей?

Здесь подробный материал:
http://rsdn.ru/article/dotnet/GC.xml

jonie, не совсем. См. здесь. GC в .NET, как и любой другой GC, основан на понятии достижимости объекта.
Подсчёт ссылок, во-первых, пасует перед циклическими ссылками, во-вторых, медленнее, особенно в многопоточном окружении (каждое изменение счётчика требует блокировки!).

Это сообщение отредактировал(а) Void - 19.8.2007, 22:07

именно это я и говорил! я говорил что НЕТ необходимости дефрагментировать кучу каждый раз, а вот вызвать деструктор, почему бы и нет?. Равно как и освобождать память объекта.
Т.е. моя бы схема была такова : объект вышел за пределы видимости -> уменьшили внутеренее количичество ссылок на него -> если это количество нуль - то вызвать деструктор... когда-нить запустить обычную сборку мусора (ориентирование удалять\нет - по счетчику ссылок).... вот почему не так я до сих пор не понима   по мне так это напрашивается... но видимо в M$ увидели в таком подходе каой-то изъян.. вот и думаю какой)
------
Void Во.. терь увидел иъян ) хотя насчет производительности и удобства я бы поспорил... как гриться нада больше тестов 8) тему прикрываю.

Это сообщение отредактировал(а) jonie - 19.8.2007, 22:09

А вот создание новых объектов идёт с учётом того, что куча отдефрагментирована => нет смысла искать область памяти, которой будет достаточно для размещения нового экземпляра объекта. Есть обычный указатель на самый верхний объект в куче, его и используют для рассчёта адреса следующего нового объекта. А освобождать память каждый раз не вижу смысла, сборщик мусора за нами всё уберёт, как нужно будет 

Linux я хз как те еще сказать что я имею в виду)... я говорил лишь про вызов деструктора в стиле С++ , все остальное пусть так же и остается 8-)

В NET хорошим стилем считается вызов Dispose для освобождения ресурсов, занятых объектом. Работа деструкторов (финализаторов) не детерминированна, так как освобождение памяти происходит в 2 прохода GC. Определитесь с вопросом, чего требуется.

P.S. Здесь вместо вызова деструктора (как в С++) лучше вызвать Dispose(), и затем потерять ссылку на объект. GC потом подберёт.

Dispose применяют для немедленной чистки неуправляемых ресурсов (всякие хендлы и.т.п), а сам объект так же уничтожается GC. По части работы GC очень подробно описано на сайте MSDN или у Рихтера в книге.