Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.08.12;
Скачать: CL | DM;

Вниз

передача объекта по ссылке   Найти похожие ветки 

 
sydenis   (2007-07-11 12:21) [0]

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


 
tesseract ©   (2007-07-11 12:22) [1]

Никакой. Все объекты передаються по ссылке.


 
Сергей М. ©   (2007-07-11 12:33) [2]


> Какая разница между Proc1(Obj: TMyObject) и Proc1(var Obj:
>  TMyObject)?


В 1-м случае передается собственно ссылка на объект, во 2-м - ссылка на переменную, содержащую ссылку на объект (т.н. косвенная ссылка)


 
ЮЮ ©   (2007-07-11 12:43) [3]

Во втором случае в ходе работы процедуры можно заменить Obj на другой объект класса TMyObject, в первом - довольствоваться только переданным Obj - его методами и свойствами


 
Ega23 ©   (2007-07-11 12:44) [4]


> Никакой. Все объекты передаються по ссылке.


Вообще-то разница есть. Допустим во время передачи объекта не существует (Obj=nil). А в процедуре стоит проверка, типа если не существует, то - создать.
В таком случае надо как var передавать.
Во всех остальных - пофиг.


 
StriderMan ©   (2007-07-11 12:54) [5]


> А в процедуре стоит проверка, типа если не существует, то
> - создать.

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


 
Ega23 ©   (2007-07-11 12:56) [6]


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


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


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

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


 
sydenis   (2007-07-11 13:07) [8]

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


 
Reindeer Moss Eater ©   (2007-07-11 13:07) [9]

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


 
StriderMan ©   (2007-07-11 13:55) [10]


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

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

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


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

> sydenis   (11.07.07 13:07) [8]

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


 
Ega23 ©   (2007-07-11 15:06) [12]


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


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


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

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


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

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


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


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

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

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

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


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

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


 
Ega23 ©   (2007-07-11 15:27) [16]


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


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


 
StriderMan ©   (2007-07-11 15:30) [17]


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

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


 
Ega23 ©   (2007-07-11 15:59) [18]


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


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


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


> sydenis   (11.07.07 13:07) [8]


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


 
StriderMan ©   (2007-07-11 16:27) [20]


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

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


 
Ega23 ©   (2007-07-11 16:37) [21]


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


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


 
StriderMan ©   (2007-07-11 18:38) [22]


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

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


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

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

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


 
oxffff ©   (2007-07-11 21:52) [24]


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


Где?


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

> Юрий Зотов

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

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



Страницы: 1 вся ветка

Текущий архив: 2007.08.12;
Скачать: CL | DM;

Наверх




Память: 0.53 MB
Время: 0.029 c
2-1184586933
Димыч
2007-07-16 15:55
2007.08.12
Юникод


2-1184226969
DINOEL
2007-07-12 11:56
2007.08.12
Проблема в передачи данных с одной формы в другую


1-1181129428
oleg_teacher
2007-06-06 15:30
2007.08.12
Как узнать для какого обекта было вызвано


2-1184572332
L2
2007-07-16 11:52
2007.08.12
Вычисляемые поля


2-1184854326
kyro
2007-07-19 18:12
2007.08.12
Можно ли в дбшрид дважды загрузить данные