Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

передача объекта по ссылке


Страницы:   1 2

sydenis ©   (2007-07-11 12:21:00) 

Есть класс TMyObject, экземпляр которого я собираюсь передать в процедуру. Какая разница между Proc1(Obj: TMyObject) и Proc1(var Obj: TMyObject)?


sydenis   (2007-07-13 11:29:00) [1]

> Юрий Зотов

> Если так, то, может быть, стоит использовать не объект,
> а интерфейс? Как только на реализующий его объект не останется
> ссылок, он убьется автоматически.

Да нет - всё проще. Передаваемый объект становится пропертью другого объекта и тот уж сам его прибъёт, когда будет умирать.  
Что-то типа create и assign TFont для вновь открываемой формы...


oxffff   (2007-07-11 21:52:00) [2]


> Юрий Зотов ©   (11.07.07 20:01) [23]
> > StriderMan ©   (11.07.07 16:27) [20]
>
> Смешение объектной и интерфейсной моделей. Типичная ошибка
> проектирования.


Где?


Юрий Зотов   (2007-07-11 20:01:00) [3]

> StriderMan ©   (11.07.07 16:27) [20]

Смешение объектной и интерфейсной моделей. Типичная ошибка проектирования.


StriderMan   (2007-07-11 18:38:00) [4]


> Ega23 ©   (11.07.07 16:37) [21]
> AddRef перекрой - и всё в порядке будет.

да как один из способов использовал, когда догадался в чем трабл :)


Ega23   (2007-07-11 16:37:00) [5]


>
> Пару раз наступал на грабли, что создавал объект, а для
> некоторых операций он имел еще и интерфейс. Передал куда-
> нить интерфейс, поработал с ним, вернулся - а объекта уже
> прибили :(


AddRef перекрой - и всё в порядке будет.


StriderMan   (2007-07-11 16:27:00) [6]


> решение с интерфейсами.
главное не забывать, что когда все ссылки на интерфейс пропадут - объекту кирдык.

Пару раз наступал на грабли, что создавал объект, а для некоторыхопераций он имел еще и интерфейс. Передал куда-нить интерфейс, поработал с ним, вернулся - а объекта уже прибили :(
причем при работе с интерфейсами дебаггеру частенько сносит крышу.


Сергей М.   (2007-07-11 16:14:00) [7]


> sydenis   (11.07.07 13:07) [8]


Наиболее удобным и универсальным решением "проблемы ответственности" за уничтожение передаваемого "туда-сюда" объекта будет решение с интерфейсами.


Ega23   (2007-07-11 15:59:00) [8]


> можно конечно снаружи проверить есть там что или нет, но
> раз процедурой удобнее, тогда умываю руки :)


Можно. Но в таком случае мне каждый раз перед вызовом придётся проверять, а так - один раз в процедуре написал - и дело с концом.


StriderMan   (2007-07-11 15:30:00) [9]


> Ega23 ©   (11.07.07 15:27) [16]
> Тут ведь вот какое дело: а если в моём bmp уже что-то было?

можно конечно снаружи проверить есть там что или нет, но раз процедурой удобнее, тогда умываю руки :)


Ega23   (2007-07-11 15:27:00) [10]


> bmp := SafeLoadBmp(AField: TBLOBField);
> функция соответственно возвращает то что нужно.
>
> хотя согласен разница с процедурой и var-параметром не велика.


Тут ведь вот какое дело: а если в моём bmp уже что-то было?


StriderMan   (2007-07-11 15:18:00) [11]


> Ega23 ©   (11.07.07 15:06) [12]

а почему бы как-нибудь так не сделать:

bmp := SafeLoadBmp(AField: TBLOBField);
функция соответственно возвращает то что нужно.

хотя согласен разница с процедурой и var-параметром не велика.


> Игорь Шевченко ©   (11.07.07 15:08) [14]

+1. Классика как всегда :)


Игорь Шевченко   (2007-07-11 15:08:00) [12]

Хороший пример - процедура FreeAndNil


Ega23   (2007-07-11 15:07:00) [13]

В целом - я с тобой согласен, сам я всего несколько раз такие конструкции использовал. Но, как говориться, почему бы и нет?


Ega23   (2007-07-11 15:06:00) [14]


> ниразу не сталкивался с такой необходимостью. Создаю объекты
> обычно там где задаются переменные на них указывающие. Или
> в конструкторах других классов.
>
> Крайний случай - объекты, которые создаются один раз, но
> только если они нужны. т.е. - не нужны - не создаем. Кому-
> то понадобился - создали, и оставляем на случай если еще
> понадобится.


Элементарная вещь: есть bmp : TBitmap, есть TBLOBField. В блобе лежит какая-то картинка (может bmp, может - jpg, а может и null). Нужно, чтобы в bmp лежал именно bmp. А если пусто, то bmp вообще не создавался.
Года 3 назад написал процедуру, до сих пор успешно пользую.


Юрий Зотов   (2007-07-11 14:56:00) [15]

> sydenis   (11.07.07 13:07) [8]

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


StriderMan   (2007-07-11 13:55:00) [16]


> Ega23 ©   (11.07.07 12:56) [6]
> Почему? Нормальная ситуация.

ниразу не сталкивался с такой необходимостью. Создаю объекты обычно там где задаются переменные на них указывающие. Или в конструкторах других классов.

Крайний случай - объекты, которые создаются один раз, но только если они нужны. т.е. - не нужны - не создаем. Кому-то понадобился - создали, и оставляем на случай если еще понадобится.


Reindeer Moss Eater   (2007-07-11 13:07:00) [17]

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


sydenis   (2007-07-11 13:07:00) [18]

просто объект передаётся между разными формами и та, которая его создала, может закрыться, а следить за его дальнейшей судьбой должна та, куда его передали


sydenis   (2007-07-11 13:04:00) [19]

штука в том, что в Proc1 объект убивается
поэтому хотелось бы быть уверенным - в каком случае он точно прибъётся: если var или по значению? а может в обоих случаях?
потому что процедура вызывающая Proc1 о нём уже не заботится.


Ega23   (2007-07-11 12:56:00) [20]


> лучше таких конструкций избегать, ИМХО :)


Почему? Нормальная ситуация.


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо