Еще немного про метод free и выход из процедуры

← →
Islander (2003-10-07 20:43) [0]

Говорят, что, если объект объявлен в функции или процедуре, то метод Free к нему применяется автоматически при выходе из процедуры. Так ли это? И сработает ли для следуещего примера?
Все ли объекты будут уничтожены?

Procedure lalala;
var
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Strings: TStrings;
begin

Label1:= TLabel.create (nil);
Label2:= TLabel.create (self);
Label3:= TLabel.create (Form1);
Strings:= TStringList.create;
end;

← →
Fay (2003-10-07 20:46) [1]

Ни один

← →
Islander (2003-10-07 20:50) [2]

Вы уверены?!
А как это проверить?

← →
Anatoly Podgoretsky © (2003-10-07 20:52) [3]

Это не надо проверять, иначе бы Дельфи не работала.

← →
DiamondShark © (2003-10-07 21:06) [4]

> А как это проверить?

Брекпоинт в деструкторе поставить...

← →
Fay (2003-10-07 21:10) [5]

Это (как правило) не проверяют - из этого исходят.

← →
Islander (2003-10-07 21:19) [6]

Так значит, все-таки делать free?

← →
DiamondShark © (2003-10-07 21:22) [7]

> Так значит, все-таки делать free?

Как это ни печально -- да.

← →
Семен Сорокин © (2003-10-07 21:28) [8]

2Islander
Вариант для функции:
MyObject := TMyObject.Create; try ... finally MyObject.Free end;

Вариант для объекта внутри другого:

constructor TMyClass.Create... begin MyObject := TMyObject.Create; end; destructor TMyClass.Destroy; begin MyObject.Free end;

Вариант для модуля:

... initialization MyObject := TMyObject.Create; finalization MyObject.Free end.

← →
Anatoly Podgoretsky © (2003-10-07 21:31) [9]

Если проанализивовать, то

Procedure lalala;
Label1:= TLabel.create (nil); // этот удалять
Label2:= TLabel.create (self); // ошибка компиляции
Label3:= TLabel.create (Form1); // этот необязательно
Strings:= TStringList.create; // этот удалять
end;

2 Islander (07.10.03 20:43)

в делфи нет механизма сборки мусора и неявно вызываемых деструкторов при выходе из области видимости.. Есть некоторые структуры со счетчиком использований, которые автоматически уничножаются, при сбрасывании счетчика в нуль (те же строки (не короткие), те же обьекты, удерживаемые по интерфейсной ссылке) - .. Но это не совсем то, что неявно вызываемые деструкторы в том же си.. Поэтому см. [9] Anatoly Podgoretsky © (07.10.03 21:31)

Потомки класса TConponent имеют в виртуальном конструкторе параметр create(AOwner: TComponent). Так вот, если AOwner не был nil, то такой компонент будет уничтожен при уничтожении компонента, который был передан, как AOwner. Но это хороший способ, если предполагается создавать компонент однократно. А иначе, эти компоненты, хоть и уничтожатся когда-нибудь, но если их много, могут отнимать все больше и больше ресурсов в процессе работы программы. Поэтому самый правильный и надежный способ, применимый ко всем таким товарищам, это уничтожать, если болше не используется, желательно в блоке защищенных ресурсов try-finally-end.
Я обычно даже все формы, кроме главной, создаю по мере надобности и уничтожаю, а не перечисляю в dpr, как это по умолчанию принято делать.
Но вот что касается COM-объектов, то насколько я помню, Delphi сама подсчитывает ссылки и удаляет их. Но боюсь ошибиться...

> COM-объектов, то насколько я помню, Delphi сама подсчитывает ссылки

Это не делфи делает, это требования кома, которые разработчики com-обьетов должны выполнить.. Компилятор делфи только автоматически генерирует визовы
_AddRef и _Release при работе с интерфейчными ссылками..

Зы - приходилось несколько раз наблюдать за сишными програмерами, пересевшими на делфи, и работающими с COM - и ихними вызовами _AddRef и _Release с подальшим поиском лишнего или недостающего _Release :-)

2 Ihor Osov"yak © (08.10.03 01:07) [12]
Точно! Delphi сама _AddRef и _Release тихаря юзает. Типа избавляет разработчика от головной боли.

Еще немного про метод free и выход из процедуры Найти похожие ветки