Здравствуйте, #John, Вы писали:
J>Здравствуйте, почему в первом случае не вызывается финализатор?
Финализатор, вроде, вызывается после GC, причём недетерменированно, в отдельном треде. Т.е. может быть такое, что в первом случае он зовётся, но уже после разрушения основного класса, консоли, детача дебагера и всего такого. Во втором случае, у нас есть граф зависимостей, поэтому разрушить основной класс без финализации FinalizableObject — нельзя, и финализатор получается "наблюдаемым".
Здравствуйте, Mr.Delphist, Вы писали:
MD>Финализатор, вроде, вызывается после GC, причём недетерменированно, в отдельном треде. Т.е. может быть такое, что в первом случае он зовётся, но уже после разрушения основного класса, консоли, детача дебагера и всего такого. Во втором случае, у нас есть граф зависимостей, поэтому разрушить основной класс без финализации FinalizableObject — нельзя, и финализатор получается "наблюдаемым".
Да, похоже надо вызывать метод GC.WaitForPendingFinalizers() , что бы точно убедиться что финализатор будет вызван.
Підтримати Україну у боротьбі з країною-терористом.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Во втором случае, у нас есть граф зависимостей, поэтому разрушить основной класс без финализации FinalizableObject — нельзя
FinalizableObject не зависит от Program.
Что-то я не вижу в примерах большой разницы, кроме той что во втором случае объекту FinalizableObject после отработки его финализатора будет подарена вторая жизнь.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Mr.Delphist, Вы писали:
MD>>поэтому разрушить основной класс
TK>вы в слово разрушить какой физический смысл вкладываете?
Какой-какой. До основанья! А затем...
Т.е. отмечаем, что данный блок памяти свободен, дёргаем системные API для возврата unmanaged-ресурсов, проходим по дереву связанных объектов и делаем там то же самое. По окончании — опциональный heap compaction, вот это всё.