Как человек, безумно любящий делфи, со всей приличествующей скорбью заявляю: делфи умер. Начнем с того, что Борланд, чтобы выжить, объявил о смене стратегии - он теперь "консалтинговая компания".
Во-вторых - не побоюсь этого слова, гениальность VCL и самого борландовского RAD - это заслуга Хайльсберга, который потом ушел в Майкрософт, после чего у борланда удачные нововведения как-то сразу поиссякли.
В-третьих, у Борланда после седьмого (весьма спорного в плане безглючности, да и почти не не отличающегося от шестерки) была восьмерка под дотнет (точнее, на борландовское разумение дотнета), и 2005, в которой так и не пофиксили все баги, а просто выпустили 2006 и сказали, что "там исправлены все грабли 2005" (так было прямо в анонсе).
В 2005 Борланд уже весьма беззастенчиво лег под мелкософт, реализовав как враппер "VCL-.NET" и фактически склоняя всех переходить на эту платформу.
Все знакомые дельфисты сидят под семеркой, 2002 года выпуска, а то и под шестеркой.

После чего возникает ряд вопросов:
- если писать под VCL, то зачем нужна 2005, а тем более - 2006 делфи? Разве что из-за рефакторинга?
- если писать под дотнет, то зачем использовать Делфи, где нет ни garbage collector, ни других приятностей сишарпа?
- если писать на сишарпе, то зачем использовать борландовскую студию, а не майкрософтовскую?:)

>Может вы что-то иное имели в виду, но gc никак не связан с C#. Это фича самого .NET, вне зависимости от языка программирования.

В теории - да. А на практике - все примеры, содержащие В ТОМ ЧИСЛЕ компоненты VCL, пестрят строчками .Free. Зайдите в Demos\Delphi.NET\VCL.
И в примерах по WinForms, что занимательно, эти строчки тоже есть.

Все очень просто: даже если пишешь код "как бы не под VCL", все равно пользуешься старым набором классов (TStringList, TMemoryStream и т.д.), которые тянут за собой весь VCL. А зачем компонентам VCL вызывать gc в явном виде - это уже вопрос к борланду. Подозреваю, что дельфевое приложение где-то хранит глобальный список всех объектов, что не дает gc эти объекты собрать, даже если они уже выпали из активного скоупа.
А *не* использование привычного набора классов - это уже, простите, и *не* программирование на Делфи (поскольку такого языка как Делфи, строго говоря, нет. Есть объектный паскаль и борландовский набор компонент под него, превратившийся в языковый стандарт).
Если я не прав - поправьте меня.

>да нет, насчет языка, я думаю, правда. Язык - Object Pascal, IDE - Delphi.

Вот именно. С небольшим уточнением, что кроме IDE, под Delphi подразумевался, как правило, еще и VCL в комплекте (именно поэтому практически любой программист, пишущий на делфи, с достаточной легкостью пишет-читает код для CBuilder, хотя аналогичный код на C++, но под VS/mfc вызовет у него ступор).

А насчет gc под делфи/.NET, я ничего не утверждаю - я всего лишь "что вижу, о том и пою". Если борландовцы оставили в примерах ненужные строчки просто потому что тупо скопировали примеры из Win32 - ну, что я могу сказать, лишний признак стагнации. А если нет - то зачем-то же эти строчки нужны. Ткнуть пальцем в конкретный файлы демок? Или сами поиском найдете по строчке ".Free"? Вот поэтому я и предположил, что борландовский код каким-то образом вводит дотнетный gc в заблуждение.
Типичный аналог в яве - циклические ссылки или глобальный список всех созданных объектов.

Вах-вах! Действительно, как удобно работает GC - всего-то лишь где-нибудь в MainForm.FormDestroy я должен вписать FControlList.Free;
(конкретное место: Demos\Delphi.net\VCL\FlowPanel\mainunit.pas)
или где-нибудь вставить LStrings.Free; для созданного TStringList.
(конкретно, там же, ConvertItUnit.pas)
А и правда, замечательный сборщик мусора!

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

Прекрасно понимаю. Слава Богу, уже пятый год на Яве в том числе пишу. И прекрасно знаю, что финализацию В ЯВНОМ ВИДЕ необходимо запускать крайне редко. И что в большинстве случаев, ее замечательно производит gc перед прибиванием объекта. Насильная финализация нужна крайне редко, для явного освобождения ресурсов, не дожидаясь, когда до этого места доберется мусорщик, и то не рекомендуется (например, любой поток ввода-вывода категорически не рекомендуют закрывать неявно, финализируя объект, а предлагают закрывать явно через close()).

И кто бы мне объяснил, зачем-таки нужна финализация локальному объекту TStringList, и в чем тогда весь цимус, если вместо утечек памяти у меня будут утечки ресурсов?
"Мы соберем за вас весь мусор, только вы сначала объект не забудьте финализировать". Ой, спасибо!