Garbage collector или Да ну нафиг!

NightmareZ

JAre, В плюсах и прочих используется идиома владения и RAII.

А твой высер похож на нетленное "Пастернака не читал, но осуждаю".

NightmareZ

opera.rulez, Object Pascal - верблюжье говно. Я в упор не понимаю, какому уёбищу пришло в голову сделать так, как в паскале.

Объясняю.

Одна крайность - C#. Я создаю объект с помощью оператора new, работаю с ним и забываю о нём - сборщик мусора его очистит, всё хорошо.

Другая крайность - C++. Я создаю объект на стеке, работаю с ним и забываю о нём. После выхода из области видимости, объект будет удалён. Всё хорошо.

Второй вариант для C++ - я создаю объект в куче с помощью оператора new, заворачиваю в умный указатель, созданный на стеке... а дальше работает предыдущий сценарий. Опять же, всё хорошо.

А теперь, внимание! Уёбищный говнопаскаль. Он умудрился вобрать в себя недостатки обоих крайностей.
Я создаю объект в куче (потому что хуй иначе сделаешь), работаю с ним, удаляю его. Всё вроде бы хорошо. Но, блядь, стоит выскочить эксепшену после того, как я создал объект, но до того, как я его удалил - и, оппаньки, получаем утечку памяти и/или ресурсов.

И, блядь, чтоб мне этого избежать, нужно заворачивать работу с объектом в блок try...catch...finally, что делает код похожим на кусок верблюжьего говна.

-----

Правка. Тут я разгневался и решил дописать.

Но дегенераты, разрабатывающие паскаль пошли дальше и решили добавить таки кастрированный вариант сборщика мусора (неудачное название в данном случае, но я не знаю, как ещё сказать) и, например, динамический строки (вуаля!) сами удаляются. Какого хуя? Никто не знает.

А ещё есть шикарная возможность сделать для своих классов автоматическое удаление, основанное на интерфейсах (какого хуя, тоже не ясно) и подсчёте ссылок. Но, блядь, и тут не без ложки верблюжьих экскрементов: стоит сделать циклическую зависимость - и пизда.

NightmareZ

opera.rulez, Ну по сути дела, да. Вон пишут же ядра типа Linux и подобные на C. Другое дело, что нужно быть очень-очень внимательным, и, если что, быть готовым словить ошибку из-за неверного указателя совсем в другом месте в другое время и потом долго-долго дебажить. Потому у линукс программистов борода растёт, бриться некогда.

Вот написал я самодельные двусвязный список на C#, создал его в памяти, заполнил всякой фигнёй... Что мне нужно сделать, чтобы удалить все связанные его ноды из памяти? Ничего.

А что нужно сделать в C, чтобы удалить такой же список? Нужно пройтись с самого его начала до самого конца, делая free для каждого элемента, а потом не забыть удалить самый последний элемент. Ну, а, если это не интрузивный список, то нужно ещё не забыть поубивать все элементы, находящиеся в его нодах.

Я только недавно этим занимался. Чисто для расширения кругозора решил написать на C реализацию наиболее известных структур: списков, очередей, деревьев разных. Хоть таки задачу решил и получил некий ментальный профит и повышение ЧСВ, расширил мне C больше не кругозор, а анальное отверстие. После чего мне стали сниться по ночам кошмары со Столлманом, жующим мазоли, в главной роли.

NightmareZ

JAre, Спасибо, кэп! :)

NightmareZ

opera.rulez, Нет.

Некоторые противники сборщика мусора говорят, что он жутко плох для приложений, требующих хорошей отзывчивости (игр, например).

Сторонники же в ответ пишут кошерные сборщики мусора, работающие в фоне и как-то по-доброму. Например, вон в .NET 4 мелкомягкие что-то навояли такое и кичатся этим.

Война.

NightmareZ

opera.rulez, Ну, я думаю, да.

Раз даже операционки пишут (во всяком случае пытаются) на управляемых языках со сборкой мусора (Microsoft с их Singularity; и ещё какой-то у кого-то проект был, я не помню)...

С другой стороны надо понимать, что за всё нужно платить.

NightmareZ

NightmareZ, За мой долгий опыт программирования на дотНете я пришёл к выводу, что основные тормоза не от сборщика мусора и не от managed кода.

Пример.

Есть в .NET Framework замечательный класс Bitmap, позволяющий загружать изображения из различных форматов (bmp, jpg, png...). Есть у него методы GetPixel и SetPixel. То есть теоретически, можно загрузить изображение, обработать его любым нужным тебе способом и алгоритмом и сохранить результат.

Но когда пришлось мне писать много-много разных фильтров для изображений я пришёл в уныние. Методы GetPixel и SetPixel работали жутко медленно. Ну то есть совсем-совсем. Ту задачу, которую надо было решить за (ну пусть десятки или сотни) миллисекунды, с помощью этих методов можно было выполнить за несколько секунд.

Но выход нашёлся: указатели и работа напрямую с памятью. То есть я стал загружать картинку в тот самый объект класса Bitmap, а потом в обход работать с памятью, где он лежит. Скорость выросла не в проценты и не в десятки процентов, скорость выросла в десятки раз.

А виной медленной работы Get/SetPixel был не сборщик мусора, а куча проверок внутри них (на формат пикселей изображений, на невыход за границы допустимых диапазонов, и т.д.)