Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, remission, Вы писали:

R>>Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе.
R>>И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.

AVK>Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.

ОК, переформулируем — если речь идет об ООП то программа должна явно управлять циклом жизни (lifecycle) любого обьекта который она создала и в нужный момент явно его удалить.
GC во первых — просто развращает, во вторых делает вообще невозможным поиск Memory leak-ов путем автоматическог анализа кода и очень сильно затрудняет их поиск путем Code Review.

R>>Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?
AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).
Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.
Более того, не всегда есть возможность знать заранее в каком случае "Память больше не ресурс", а когда обьект/некоторые его части были созданы на внешнем сервере, и позволить GC решать, когда он будет освобожден это непозволительная роскошь.
Даже когда разработчик исползует jdbc, он вполне может не знать, будет ли незакрытый RecordSet просто Memory leak-ом на 20kb в java машите, который исправит GC, или незакрытым курсором в БД, который "весит" десятки мегабайт.

R>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
AVK>А вот парсер R#, использующий System.String не останавливается.

Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.

R>>Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.

AVK>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью", но когда такая возможность предоставляется самой технологией, и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.
Например в Java я предпочел бы возможность решать в каждом отдельном случае делать "delete a" или "System.manageLifeTime(a)".

Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать, а в обратных случаях часто возникают большие проблеммы.