Классы!

← →
WondeRu © (2004-08-12 12:42) [0]

Здравствуйте!
Чем отличается следующий код? и где, что лучше применять?
1. (Sender as TPanel).Handle

2. TPanel(Sender).Handle

Код Делфа генерит разный!!!

Заранее спасибо!

← →
_student (2004-08-12 12:57) [1]

"Разница между традиционными преобразованиями типов и использования операции as заключается в том, что последний вызывает исключительную ситуацию."
М.К.

← →
wicked © (2004-08-12 12:59) [2]

1. выполняется проверка на то, является ли Sender экземпляром TPanel или её наследников... и если вдруг Sender окажется экземпляром TButton, наступит исключение...
2. ничего не проверяется, так что если Sender окажется экземпляром TButton, то и компилятор сгенерирует код, ведущий себя с Sender как с TButton...

на самом деле не так всё однозначно, поскольку в коде идёт обращение к свойству, общему и для TPanel, и для, скажем, TButton, поскольку обьявлено оно в общем предке - TWinControl... поэтому в данном случае катастрофы не будет...
но если вдруг в Sender окажется экземпляр, скажем, TList, то второй вариант уже чреват серьезными глюками...

в общем, совет: если нужно обратиться к свойству типа Handle или ClientRect, то кастить такой указатель лучше к классу, в котором это свойство и обьявлено... в данном случае это TWinControl...

← →
QQ (2004-08-12 13:14) [3]

В первом случае вызывается дополнительно процедура @AsClass,
которая проверяет, является ли Sender объектом класса TPanel или его наследника (если не является - генерируется исключение).
Первый вариант предпочтительнее, если речь не идёт о быстродействии. В любом случае лучше заранее проверить Sender на соответствие: if Sender is TPanel then ...

← →
KSergey © (2004-08-12 13:17) [4]

> [2] wicked © (12.08.04 12:59)
> в общем, совет: если нужно обратиться к свойству типа Handle
> или ClientRect, то кастить такой указатель лучше к классу,
> в котором это свойство и обьявлено... в данном случае это
> TWinControl...

По поводу общности совета совершенно не согласен.

> _student (12.08.04 12:57)

Извините - бред. Т.е. as всегда вызывает исключительную ситуацию, я правильно понял? (так написано!)
(традиционной и не традиционной бывает секссуальная ориентация)

Ну чем отличается - сказал wicked, е по поводу где применять - по-моему понятно: если есть полная уверенность, что некая переменная в данном месте программы точно указанного типа либо его наследник - то можно применять второе; если такой уверенности нет - первое (важно делать надежные программы).

А вообще - ну в книжках это все есть.
Да и недавно отгремела огромная вполне любопытная ветка по is. Думаю, к as это тоже относится.

← →
_student (2004-08-12 13:21) [5]

> KSergey © (12.08.04 13:17) [4]

если типы объектов ....

← →
KSergey © (2004-08-12 13:22) [6]

> [4] KSergey © (12.08.04 13:17)
> - по-моему понятно: если есть полная уверенность, что некая
> переменная в данном месте программы точно указанного типа
> либо его наследник - то можно применять второе; если такой
> уверенности нет - первое (важно делать надежные программы).

Читать так:

если есть полная (гарантированная!) уверенность, что некая переменная содержит ссылку на объект того же класса, к котрому приводится или его наследника - то можно применять второе;

и далее по тексту.

← →
KSergey © (2004-08-12 13:23) [7]

> [5] _student (12.08.04 13:21)

Да, да
Запостил, потом подумал ;)

← →
WondeRu © (2004-08-12 13:38) [8]

Вроде разъяснилось! Спасибо!

← →
Anatoly Podgoretsky © (2004-08-12 14:01) [9]

Все зависит от того, хочешь ли ты катастрофическое окончание или можно отделаться исключением.

← →
WondeRu © (2004-08-12 15:03) [10]

Ну да, а если Sender объявлен как Pointer?

← →
_student (2004-08-12 15:11) [11]

is не помогает?

← →
GrayFace © (2004-08-12 15:26) [12]

KSergey © (12.08.04 13:17) [4]
> Да и недавно отгремела огромная вполне любопытная
> ветка по is.

Можно ссылку или название?

← →
WondeRu © (2004-08-12 15:26) [13]

2 _student
is работает только с потомками TObject!!!

Если Sender - указатель, то работает только 2-й вариант(((

← →
_student (2004-08-12 15:40) [14]

Не спорю

if TObject(p) is TButton then ShowMessage("sdfg") else ShowMessage("11111");

← →
WondeRu © (2004-08-12 15:46) [15]

[14]
а если p=nil , будет ли работать код TObject(p) ?

← →
Anatoly Podgoretsky © (2004-08-12 15:53) [16]

Приведение типа не делает никакого предположения об содержимом переменной

← →
s999 (2004-08-12 15:54) [17]

> а если p=nil , будет ли работать код TObject(p) ?

Вполне. Порой даже без ошибок, например:

ShowMessage(TLabel(nil).Caption);

← →
ALS © (2004-08-12 16:05) [18]

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

← →
_student (2004-08-12 16:08) [19]

p:=Label1; if TButton(p) is TButton then ShowMessage("sdfg") else ShowMessage("11111");

Выдает что p TButton. Да, это все надуманная бредятина.

2s999 (12.08.04 15:54) [17]
а такой код

TLabel(nil).Canvas.Lock;

????

Боюсь фокусы с ShowMessage(TLabel(nil).Caption - частный случай, т.к в конце концов ShowMessage отрисовывается DrawText, в которую передается не строка, а указатель на нее (PChar) в данном случае nil!

> [20] WondeRu © (12.08.04 16:09)
> Боюсь фокусы с ShowMessage(TLabel(nil).Caption - частный
> случай, т.к в конце концов ShowMessage отрисовывается DrawText,
> в которую передается не строка, а указатель на нее (PChar)
> в данном случае nil!

Нет, он не nil (ну так вот уж, гарантированно), но, вероятно, попадаем в допустимую область памяти.
Впрочем, на самом деле это очень зависит от положения луны относительно созвездия псов. Совершенно серьезно.

> [19] _student (12.08.04 16:08)
> p:=Label1;
> if TButton(p) is TButton then
> ShowMessage("sdfg")
> else
> ShowMessage("11111");
>
> Выдает что p TButton. Да, это все надуманная бредятина.

В упомянуой мной ветке это подробнейше обсуждалось.
Было в потрепаться.
сейчас попробую поискать

← →
s999 (2004-08-12 16:20) [22]

> Боюсь фокусы с ShowMessage(TLabel(nil).Caption - частный
> случай

Конечно.

> Боюсь фокусы с ShowMessage(TLabel(nil).Caption - частный
> случай, т.к в конце концов ShowMessage отрисовывается DrawText,
> в которую передается не строка, а указатель на нее (PChar)
> в данном случае nil!

Не совсем так, просто у TControl метод GetText любопытно реализован.

А вообще, нормально отработают методы, которым конкретный экземпляр класса "по барабану".

>_student (12.08.04 16:08) [19]
хороший код - хорошо работает! мне понравилось! ;-)

>s999 (12.08.04 16:20) [22]
>А вообще, нормально отработают методы, которым конкретный экземпляр класса "по барабану".

если объявлен как class procedure, то м.б.! или я не прав?

2ALS © (12.08.04 16:05) [18]
интерфейсы только через ass должны браться ;-)

Обещанные ссылки:

Увы, та ветка уже в архиве, кому интересно можно взять тут (спасибо клиенту форума!)
FTP://217.70.127.139/incoming/Forum/1.html

так же не плохая была
http://delphimaster.net/view/15-1091522317/

← →
s999 (2004-08-12 16:39) [26]

> если объявлен как class procedure

Совсем не обязательно. Например:

TMyObject = class(TObject)
public
Str: string;
procedure Proc1;
procedure Proc2;
end;

procedure TMyObject.Proc1;
begin
ShowMessage("Ляля");
end;

procedure TMyObject.Proc2;
begin
ShowMessage(Str);
end;

А теперь:

TMyObject(nil).Proc1;
TMyObject(nil).Proc2;

Первый вызов работает, второй нет. Первому просто ничего от объекта не надо.

_student (12.08.04 16:08) [19]
Бредятина у тебя ты явно попросил компидятор не беспокоиться насчет проверки, что TButton это TButton

Классы! Найти похожие ветки