Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

image:=TImage.Create(Application);

wsih © (2006-05-28 23:21:00)
Правильно ли это иделолгически, этически и тп...
Я так понимаю у визуальных компонентов в конструктор передается кто-то, кто будет отвечать за высвобождение памяти. Наставте на путь истинный...

TUser (2006-05-29 04:43:00) [1]
Если объект лежит себе на форме и менять Parent не предполагается (а обычно это так для TComponent) - то, имхо, лучше и оунером сделать эту форму, а не nil и не Application. А то что получиться, если этих форм будет создано 500 штук в цикле создать-поработать-закрыть-создать ...

Palladin (2006-05-29 01:21:00) [2]

> unknown © (29.05.06 00:52) [8]

в случае с TImage да... использовать сразу в нескольких созданных формах не получится (если они одновременно отображаются конечно), точнее получится если пользоваться BitBlt, и работать с этим объектом лучше в конктесте той формы которая использует его... но есть одно но... Application можно назначать владельцем для "тяжелых" на подьем компонентов и/или мелких и очень очень часто использующихся (например в циклах из разных методов и классов)... и в случае TImage если изображение довольно объемное, что проявляется ощутимая задержка при его создании, то, думаю, стоит все таки создать глобальный объект и BitBlt'ить его на созданные TImage на форме (с владельцем формой конечно)...

ну а по поводу мем ликов, ну они не совсем мемлики технически, Application то о них помнит, но организационно, я согласен, они таковыми являются :) да и я уже высказался по этому поводу в [6]

> wsih © (29.05.06 01:06) [9]

Утечки памяти

wsih (2006-05-29 01:06:00) [3]
А кто такие мемлики? =О

unknown (2006-05-29 00:52:00) [4]

> Palladin © (29.05.06 00:06) [3]
> Почему неправильно?

Я изначально хотел пояснить, даже несколько строчек написАл
(правда потом стер :)), но ведь задачи разные бывают и
в большинстве случаев image:=TImage.Create(Application); некорректно,
бо можно мемликов поиметь :)

wsih (2006-05-29 00:35:00) [5]
Спасибо, именно это и хотел услышать. :)

Palladin (2006-05-29 00:23:00) [6]

> wsih © (29.05.06 00:16) [5]

А вот это утверждение уже не есть хорошо ибо грозит тем, что в результате может расплодится куча объектов одноразового использования, которые так и застряну в Application до локального конца света. Если объект используется один раз или несколько, но только в одном контесте (скажем в теле процедуры или метода) то лучше в параметре конструктора использовать Nil и освобождать вручную после отработки. Стандартная конструкция выглядит как.

SomeComponent:=TSomeComponent.Create(Nil);
Try
...
Finally
SomeComponent.Free;
End;

или при необходимости

SomeComponent:=TSomeComponent.Create(Nil);
Try
Try
...
Except
<обработка исключений>
End;
Finally
SomeComponent.Free;
End;

wsih (2006-05-29 00:16:00) [7]
В общем я понимаю так - всему, что создается динамически и требует в конструкторе хозяина можно ставить Application и не заботится об их последующей судьбе, так как за меня это сделает Aplication при своем терминировании.

Palladin (2006-05-29 00:10:00) [8]

> Правильно ли это иделолгически, этически и тп...

При такой постановке вопроса рассматривать с этих сторон практически нечего. Нужно рассматривать конкретные случаи.

> Я так понимаю у визуальных компонентов в конструктор передается
> кто-то, кто будет отвечать за высвобождение памяти.

Не у визуальных компонентов, а у всех наследников TComponent. В остальном ты понимаешь правильно.

Palladin (2006-05-29 00:06:00) [9]

> unknown © (28.05.06 23:37) [1]

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

wsih (2006-05-28 23:44:00) [10]

> Нет, не правильно.

Так и знал. А почему? )...

unknown (2006-05-28 23:37:00) [11]
Нет, не правильно.
> Я так понимаю
Да.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »