Ответ на »сообщение 736« (Антон Григорьев)
___________________________

Про использование with в Python уже рассказали. Если нет много времени на изучение этого механизма, то можно почитать об этом в Маниакальном веблоге

Противники GC всегда готовы привести массу примеров, когда это неудобно. Но даже "под дулом пистолета" отказываются признавать, что в их жизни были такие случаи, когда ручное управление памятью для множества объектов, передаваемых между контейнерами, превращалось в сущий кошмар.
Интерфейсы тоже не всегда спасают. Во-первых, надо или руками реализовать в своем классе IUnknown (что, вообще говоря, не очень страшно, только QueryInterface мешается), или получить серьезные ограничения по наследованию. Во-вторых, если бы там действительно все было просто, мы бы не имели проблем с агрегацией, weak references и тому подобными вещами. А в сложных системах такие проблемы возникают с завидной регулярностью.

Ответ на »сообщение 743« (Trurl)
___________________________

Но в любом случае эти проблемы - не повод отказываться от сборщика мусора совсем.

Не повод. Но этот сборщик требует серьёзной доработки с этой точки зрения.

Ответ на »сообщение 741« (Антон Григорьев)
___________________________
>>>не решаемы в принципе (по крайней мере, некоторые из них).
Вообще говоря, решаемы, хотя и не просто. Некоторые можно решить на уровне стандартных библиотек, другие
требуют решения на уровне ОС.
Но в любом случае эти проблемы - не повод отказываться от сборщика мусора совсем.

Ответ на »сообщение 739« (Jack Of Shadows)
___________________________
Насколько я понимаю, with-file, with-connection, или using SomeClass не более чем "syntactic sugar", и к сборщику мусора отношения не имеет.

В принципе я бы от using в Delphi не отказался... хотя... новые синтаксические конструкции из-за двух лишних строчек кода?

Ответ на »сообщение 738« (Trurl)
___________________________
Всё правильно, только проблемы, вызванные отсутствием сборщика мусора решаемы, хотя и портят много нервов, а вот вызванные наличием - не решаемы в принципе (по крайней мере, некоторые из них).

Ответ на »сообщение 739« (Jack Of Shadows)
___________________________
Ага, работал я с этим with (точнее, using) в шарпе. Я уж молчу про то, как приходится IDisposable для этого реализовывать, но главное - эти конструкции подходят там же, где и try..finally, т.е. когда время жизни объекта обозримо и ограничивается одним блоком. А если вы создаёте объект, который будет использован в другом месте другим кодом, который не вы писали, и освободится должен без вашего участия тогда, когда этот код перестанет в нём нуждаться, и вы даже не знаете, когда это произойдёт... Не знаю, как там в питоне, но в C# этот самый using точно не помощник.

Ответ на »сообщение 734« (Сергей Тарасов)
___________________________
В подобной "сдаче позиций" есть несомненный плюс. Компонентокидатели в течение последних лет перебежали на пошарпанный си He ну плюсы всегда можно найти, особенно их много на кладбище :) Есть правда один нюанс: вчерашний батонокидатель, завтра может оказаться твоим директором :o[

Ответ на »сообщение 736« (Антон Григорьев)
___________________________
Уже было обсуждение освобождения рессурсов (не памяти) на функциональной ветке.
Питон и сишарп совсем недаво внедрили идею из лиспа.
with-file, with-connection, with-socket итд.
Ну а дельфистам придется по старинке try finally :))

Ответ на »сообщение 736« (Антон Григорьев)
___________________________


GC - очень удобная штука, пока речь идёт об объектах, которые из всех ресурсов используют только память.
Таких объектов могут быть миллионы, а количество объектов c дефицитныим ресурсами вполне обозримю.

Сейчас мы делаем ObjectList.Free, он вызывает деструкторы всех объектов, и все ресурсы освобождены.
А если  у нас есть другой TObjectList с теми же объектами?

Ответ на »сообщение 735« (panda)
___________________________
Поборники сборщика мусора обычно выдвигают две идеи:
1. Нет необходимости писать try - finally Class.Free end;
2. Меньше утечек памяти.

Но для native-приложений мы и так уже имеем автоматическое освобождение памяти - при использовании интерфейсов. Так что народ уже имеет здесь выбор, если нет желания писать Free.

Что касается утечек памяти - благодаря FastMM я забыл что это такое.

Ответ на »сообщение 735« (panda)
___________________________

А вот Garbage Collection для Win32 мне лично кажется вредной идеей.
А мне - полезной. Будем спорить? ;-)

GC - очень удобная штука, пока речь идёт об объектах, которые из всех ресурсов используют только память. А теперь, положим, у вас есть объект типа TConnection - его деструктор не только освобождает память, но и закрывает соединение с базой. Допустим, нам этот объект уже не нужен, но он продолжает висеть в памяти, расходуя дефицитный ресурс - подключение к БД, - потому что памяти много и GC не торопится. Для каждого отдельного объекта предусмотреть такой механизм очень просто, но что делать, если у нас есть TObjectList разнородных объектов? Сейчас мы делаем ObjectList.Free, он вызывает деструкторы всех объектов, и все ресурсы освобождены. Чтобы сделать такое в языке со сборщиком мусора, надо сделать в самом базовом классе некий аналог деструктора, чтобы TObjectList и подобные умел освобождать любой объект. А так мы снова приходим к ручному управлению ресурсами, причём, если немного подумать, становится понятно, что при автоматическом управлении памятью и ручном управлении прочими ресурсами возникают конфликты. И один такой конфликт может перечеркнуть все достоинства сборщика мусора.