В D2005 есть сборщик мусора? Если есть, то как он работает?
При потере последней ссылки на объект просто освобождается память или вызывается его деструктор? По идее, после создания формы, должно появиться сообщение, но его нет...

procedure TWinForm.TWinForm_Load(sender: System.Object; e: System.EventArgs);
var
 T: TTest;
begin
 T := TTest.Create;
end;

destructor TTest.Destroy;
begin
 MessageBox.Show('убит');
 inherited;
end;

Спасибо, дельная статья -)

В общем, весело.
Получается, что destructor в Delphi2005 вовсе не деструктор, а что-то типа необязательного finalize() в Java, в этом случае процедура переноса огромного числа приложений резко усложняется.

Семантика работы с абстракциями, не завязанных напрямую на платформу Win32, например: графы, списки, коллекции, ассоциативные массивы и т.д. в .Net изменилась, придётся переписывать заново очень много прикладного кода, который до этого являлся практически кросс-платформенным (с лёгким портированием в Linux). И опять завязка на одну вполне конкретную платформу .Net, которая работает только в Windows.

Ну почему нельзя было сделать unmanaged destructor?
Снова и снова убеждаюсь, как легко борландовцам удаётся подложить очередную свинюшку при выходе новой версии. ;(

> И опять завязка на одну вполне конкретную платформу .Net,
> которая работает только в Windows.

Рихтер обещает, что т.к. cls будет скоро специфицирован, то нужно ждать реализаций для разных платформ.


> Снова и снова убеждаюсь, как легко борландовцам удаётся
> подложить очередную свинюшку при выходе новой версии. ;(

Думаю, что это особенность не Borland, а вообще net.

>>iZEN ©   (11.08.05 09:45) [4]

А при чём здесь Борланд? Отсутсвие явных деструкторов – концепция .NET Framework, а не Delphi.NET.

> А при чём здесь Борланд?

Ну так вся .NET тоже творение преимущественно специалистов Borland, только сменивших работодателя

Lamer@fools.ua ©   (11.08.05 12:52) [6].
Так зачем же ключевое слово destructor использовать вне семантики деструктора? Использовали бы существующее ключевое слово finalize (как ключевое слово class в контексте методов класса) в контексте метода и прблемы бы НЕ СТОЯЛО.

А деструктор должен оставать таким, каким был - для него должна быть обёртка в unmanaged-коде и фсё.

>>iZEN ©   (11.08.05 23:30) [8]

>Так зачем же ключевое слово destructor использовать вне семантики деструктора?

В C# деструкторы являются на самом деле финализаторами.
>The destructor implicitly calls the Object.Finalize method on the object's base class. Therefore, the preceding destructor code is implicitly translated to:

protected override void Finalize()
{
  try
  {
     // Cleanup statements.
  }
  finally
  {
     base.Finalize();
  }
}

Подозреваю, что в Delphi.NET аналогично.

>А деструктор должен оставать таким, каким был - для него должна быть обёртка в unmanaged-коде и фсё.

Деструктор ничего никому не должен. Лично мне больше нравится идея с подсчётом ссылок на объекты, как в COM, а не поиском недействительных ссылок, как в .NET GC. В последнем случае явный вызов деструктора чреват лишним геморроем: если мы явно вызываем деструктор, а на объект ещё N ссылок, то что делать? Очистить ссылки? Но их может быть много и время их поиска сравнимо со временем работы метода
.

> Лично мне больше нравится идея с подсчётом ссылок на объекты,


Мне лично тоже больше нравится - т.к. процесс более прозрачный.

Но, насколько я понимаю, сбор мусора потенциально имеет большее быстродействие в плане создания новых объектов. Например, если взять java то там ВСЕ объект. Даже int. Вроде в net тоже (только там структуры еще есть).

Но поговорим про java, т.к. я ее лучше знаю. Если ты представляешь все объектами, то должен быть эффективный способ выделения памяти под каждый объект. Если есть, например, метод, который оперирует с классом Date, то глупо каждый раз при входе в метод выделять под значение Date память. Намного правильнее найти неиспользуемый объект и использовать его. К тому же все эти фреймворковые языки (java и net) оставляют за собой право проводить оптимизацию "на лету" на основе накопленного опыта (это я читал в Рихтере по net и Эккеле по java). Как мне кажется, если бы был подсчет ссылок, то такая оптимизация была более затруднительной.

Т.е., как я понимаю, сбор мусора имеет лучше перспективы создания быстрого кода на фреймворковых языках, чем подсчет ссылок.

> Получается, что destructor в Delphi2005 вовсе не деструктор,
> а что-то типа необязательного finalize() в Java


Безусловно

>>Суслик ©   (12.08.05 09:58) [10]

>Намного правильнее найти неиспользуемый объект и использовать его.

Я не знаю, как в Java, а в .NET сборщик мусора, AFAIR, упаковывает память, посему такого понятия, как "неиспользумый объект" в Вашем контексте, вроде, нету.

>К тому же все эти фреймворковые языки (java и net) оставляют за собой право проводить оптимизацию "на лету" на основе накопленного опыта (это я читал в Рихтере по net и Эккеле по java). Как мне кажется, если бы был подсчет ссылок, то такая оптимизация была более затруднительной.

Именно. Оставляют за собой право. Причём только за собой. И это "минус", IMHO.

P.S.
О внутренностях работы с памятью в .NET:
http://www.microsoft.com/Rus/Msdn/Magazine/2005/05/InsideNet.mspx

> [12] Lamer@fools.ua ©   (12.08.05 10:45)


> Именно. Оставляют за собой право. Причём только за собой.
> И это "минус", IMHO.


Кто знает, как это будет. Вдруг jit compilers станут такими умными, что будут работать быстрее родного машинного кода. :)

Я думаю, что они сборку мусора сделали изменно исходя из этих принципов.

PS. Все, что сказал - досужие домыслы на основе анализа того, что знаю про java и net, и на основе личного опыта написания интерпретаторов.