Здравствуйте, __kot2, Вы писали:
__>ну вы же сталкивались с тем, что у нас некоторые обьекты держат указатели на системные ресурсы как файлы, хэндлы, потоки. если вы не будете их руками освобождать в dispose у вас приложение будет нестабильно падать по out of resources
И причем тут память?
И зачем хранить в поле класса ссылку на файл?
И в чем проблема если файл закроется не сразу, а после срабатывания ГЦ?
Хоть раз в жизни видел падение от того что хендлы кончались? Я нет, хотя есть подозрение что побольше тебя .Net приложений видел.
В курсе что code analysis в студии показывает все места с незадиспозенным idisposable?

__>в C#-Java вы начинаете писать код в стиле
__>using (...)
__>симулирую auto_ptr. а вот reference couring ptr вам не удастся никаикм образом добиться и придется мучаться технологиями многолетней давности
Курил? Каким образом auto_ptr похож на using?



__>потом вдруг вы столнетесь, что с большими кусками памяти та же история — дефрагментации памяти слишком тяжелая и по уму хорошо бы иметь заранее выделенные буферы или какое-то ручное более низкоуровневое управление памятью — когда большие буферы не перемешаны с мелкими временными обьектами
Это в с++ оно лучше, а с gc долгоживущие и короткоживущие объекты и так вместе не живут буквально после пары сборок мусора.


__>в итоге у вас получится полностью ручной memory management. хрень полнейшая.
Ты представляешь такой класс программистов, который на любом языке может писать как на с++. Я тебя расстрою, описанных тобой проблем просто не существует. Они есть только в с++, а в языках с ГЦ ты в микроскоп не увидишь эти проблемы, даже если тщательно воспроизведешь все условия.