Тогда все нетривиальные типы надо будет требовать как IDisposable или каким-то ещё образом гвардить. Да и вообще, GC тут скорее не часть C# как языка, а элемент NET-фреймоврка. Что он будет нам вменять, то и будем вынуждены пользовать. Вон, в некоторых микроконтроллерах динамической кучи нет — вся аллокация либо на стеке (и без того небольшом), либо глобальная переменная. И живут люди ведь как-то...
Здравствуйте, Mr.Delphist, Вы писали:
MD>Тогда все нетривиальные типы надо будет требовать как IDisposable или каким-то ещё образом гвардить.
И тем не менее, это не поможет. Оператора delete в языке нету. А IDisposable.Dispose() по спецификации не имеет права убивать объект — на нём можно продолжать делать аызовы, получая ObjectDisposedException.
MD>Да и вообще, GC тут скорее не часть C# как языка, а элемент NET-фреймоврка.
Вот как раз тут он — как часть языка. C#, как и Java, очень-очень сильно завязан на GC.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Одно время ходили слухи про "M#" — микрософтовский язык с синтаксисом шарпа для системного программирования, но Хейлсберг в интервью говорил, что это глупая затея, так как язык спроектирован специально под GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Тогда все нетривиальные типы надо будет требовать как IDisposable
BDA>А можно пример?
Пример типа в контексте использования, имелось в виду.
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Сабж.
ЕА>Вместо до-диез получиться до-бемоль
ЕА>Одно время ходили слухи про "M#" — микрософтовский язык с синтаксисом шарпа для системного программирования, но Хейлсберг в интервью говорил, что это глупая затея, так как язык спроектирован специально под GC.
Был еще проект сингулярити http://rsdn.ru/article/singularity/singularity.xml
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Здравствуйте, Mr.Delphist, Вы писали:
MD>>>Тогда все нетривиальные типы надо будет требовать как IDisposable
BDA>>А можно пример?
BDA>Пример типа в контексте использования, имелось в виду.
Ну дык:
using (var c1 = new Class()) // компилятор доволен, всё хорошо
{
/* ...причиняем добро... */
} // c1 авто-диспозитсяvar c2 = new Class(); // компилятор даёт по щам - ибо как и когда диспозить будем?
MD>var c2 = new Class(); // компилятор даёт по щам - ибо как и когда диспозить будем?
MD>
Разумеется, отказавшись от GC пришлось бы на смену ему вводить ручное удаление (если не автоматом, то руками, так ведь? Тертиум-таки нон датур?). Введя ручное удаление, надо делать его обработчики (деструкторы). А вопрос был, что от языка при этом еще открутится и отвалится (подозреваю, что жопа).
Здравствуйте, Ionich, Вы писали:
I>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>Сабж.
I>А зачем?
Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Разумеется, отказавшись от GC пришлось бы на смену ему вводить ручное удаление (если не автоматом, то руками, так ведь? Тертиум-таки нон датур?). Введя ручное удаление, надо делать его обработчики (деструкторы). А вопрос был, что от языка при этом еще открутится и отвалится (подозреваю, что жопа).
Да, мне тут на данную тему Objective-C вспомнился, с его двояким memory management — хочешь ref-counting юзай (и авто-удаление), хочешь всё в ручном режиме (но есть риск утчеки, т.к. всё самому надо делать). В принципе, сделать на этой идее Objective C# тоже можно
Здравствуйте, amater, Вы писали:
I>>А зачем?
A>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
Здравствуйте, amater, Вы писали:
A>Здравствуйте, Ionich, Вы писали:
I>>Здравствуйте, 0BD11A0D, Вы писали:
BDA>>>Сабж.
I>>А зачем?
A>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
Windows — не система реального времени, зачем ей realtime gc?
Здравствуйте, gandjustas, Вы писали:
A>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
G>Windows — не система реального времени, зачем ей realtime gc?
А как же WinCE? Под ней же тоже можно запускать .Net приложения
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, amater, Вы писали:
I>>>А зачем?
A>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
BDA>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?
Кроме того в .NET можно вручную выделять память и обращаться ней по указателю.
Здравствуйте, Ionich, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
A>>>Пригодилось бы для приложений реального времени. Хотя я подозреваю что было бы выгоднее сделать не ручное освобождение памяти, а предсказуемо управляемый GC.
G>>Windows — не система реального времени, зачем ей realtime gc?
I>А как же WinCE? Под ней же тоже можно запускать .Net приложения
WinCE сдох давно. В WP для пользовательских приложений не поддерживает real time, нет никаких гарантий, что в приложение придет сигнал от системы в заранее определенный интервал с момента возникновения события, соответственно и realtime gc не нужен.
Здравствуйте, gandjustas, Вы писали:
BDA>>Конфигурируемый во всех деталях. Per app. Но, видимо, опять какие-то параноики по соображениям безопасности запретили.
G>А сейчас деталей мало? Ты можешь в любой момент отключить GC, можешь в любой момент инициировать сборку мусора, можешь получать оповещения о приближении сборки мусора. Что тебе еще надо?
Тут где-то лежит статья Ткачева с графиками, в которой он рассказывает, как находил точку, где GC начинает безнадежно просирать Win Heap. Не помню, переходит ли он к вопросу о скрытых параметрах, приводящих к этой картине или довольствуется констатацией. А я же говорю про конфигурирование этих параметров.
Проще говоря, если дев заранее знает, что будет работать с таким или сяким количеством объектов, GC не должен переаллоцировать память в указанных пределах. С одной стороны, возрастет скорость памятеемких приложений (в соответствии с тем графиком). С другой, простейшее приложение не будет отжирать виртуальную память. Беды в этом нет, виртуальная память — очень дешевый ресурс (это просто маркировка куска свопа), но дергать диск лишний раз не придется. Для оптимизации настроек на этапе разработки можно было бы использовать профайлер, гоняя апп с типичными данными.
Это отдельная тема (от темы последствий полного убирания GC), просто я тоже всегда считал, что если сделать GC конфигурируемым, это лучше решит те проблемы, ради решения которых предлагается отказаться от GC вообще.
