Оператор IS небезопасен для форм - продолжаем разговор

← →
Григорьев Антон © (2004-07-14 18:15) [0]

Только теперь продолжаем его без оскорблений, ОК?

Piter © (14.07.04 17:53) [150]

Э-э-э, Антон, тебя не туда понесло. Я и не говорил, что IS должна работать корректно, если объект уничтожен.

Я про то, что если:

var sc: TSameClass
...
sc := Pointer(5555);
if sc is TSameClass

так вот я за то, чтобы здесь был AV.

А какая разница-то? И в том, и в другом случае имеем указатель, который указывает чёрт знает куда, а то, что в одном случае по этому указателю ранее размещался объект, а в другом - нет, ни на что не влияет.

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

> зачистка памяти. То есть, обнуление памяти, где распологался объект. А не просто объявление этой памяти свободной.

Не получится. Многим операциям это будет по барабану. Например, обращение к полю просто вернёт нулевое значение этого поля, а AV не будет. А вот снизить производительность приложения таким образом можно весьма существенно.

Жду новых идей на эту тему.

← →
vuk © (2004-07-14 18:18) [1]

>Жду новых идей на эту тему.
Я обычно стараюсь писать FreeAndNil вместо SomeObject.Free.

← →
Reindeer Moss Eater © (2004-07-14 18:22) [2]

Оператор IS небезопасен для форм

Если объект есть, то IS безопасен.

Если объекта нет, то IS "опасен". Но только не для форм, потому что самой формы нет.

Все еще ломаете копья?

← →
Григорьев Антон © (2004-07-14 18:28) [3]

> Reindeer Moss Eater © (14.07.04 18:22) [2]
>
> Все еще ломаете копья?

Да, ломаю :)) Я вижу, что Piter неглупый человек, только в теории пока не очень подкован, и мне хочется натолкнуть его на то, чтобы он разобарлся, во-первых, как всё реализовано, а во-вторых, почему именно так, и какие могут быть альтернативы. И какие у каждой из альтернатив достоинства и недостатки.

← →
Reindeer Moss Eater © (2004-07-14 18:28) [4]

Вся та ветка какой-то бред.

Человек имел код:
var
frm : TForm;
begin
frm := TForm1.Create(nil);
frm.Free ;
if frm is TForm1 then ;
end;

Из которого сделал гениально открытие об опастности IS.

Если бы он расширил свой код, то мог бы сделать гораздо более гениальное открытие о том, что все методы и свойства TForm небезопастны для форм.

И эта ветка продолжает существовать претерпев реинкарнацию.
Смех.

← →
Тимохов © (2004-07-14 18:32) [5]

> Reindeer Moss Eater © (14.07.04 18:28) [4]

> Из которого сделал гениально открытие об опастности IS.

неправда. не в этом была суть ветки. Вы невнимательно прочли ветку.

в середине он признался, что и тема названа неудачно была, и понимал он все неверно.

Но!!! Один факт он раскопал - это несоответсвие семантики is и ее описания. В этом и толко в этом есть суть высказывания автора той ветки.

← →
ИдиотЪ (2004-07-14 18:32) [6]

Reindeer Moss Eater ©
они уже давно о другом, хотя кто знает, мож это другая грань непонимания или несогласия

← →
Тимохов © (2004-07-14 18:34) [7]

> Григорьев Антон © (14.07.04 18:28) [3]
>... его на то, чтобы он разобарлся, во-первых, как всё реализовано...
>

Антон, будто вы знаете как это реализовано? :))) Сейчас поясню мысль. :))) Очевидно, что здесь есть определенный compile time. Да есть. Но отсюда следует, чтобы разобраться нужно просмотреть компилятор :))) Врядли это кто-то делал?

← →
Reindeer Moss Eater © (2004-07-14 18:34) [8]

неправда. не в этом была суть ветки. Вы невнимательно прочли ветку.

Это тема ветки.
Если бы автору открытия в первом посте рассказали о небезопастности ВСЕХ методов и ВСЕХ свойств TForm, то самой ветки бы не было в том ее виде.

Вот и все.

← →
Тимохов © (2004-07-14 18:36) [9]

> ИдиотЪ (14.07.04 18:32) [6]
> Reindeer Moss Eater ©
> они уже давно о другом, хотя кто знает, мож это другая грань
> непонимания или несогласия

Да все он понимает - даже согласился.
Единственно, в чем я думаю он ошибается, так это в том, что он до сих пор считает, что is работает неверно. Хотя позиция нашей с Антоном партии (кстати, вступайте) состоит в том, что всего лишь дока не соответствует реализации и все.

← →
Тимохов © (2004-07-14 18:37) [10]

> Reindeer Moss Eater © (14.07.04 18:34) [8]

> Это тема ветки.

Он признал, что тема неудачная. Мне лень искать, но утром я явно видел эти слова.

← →
Григорьев Антон © (2004-07-14 18:39) [11]

> Тимохов © (14.07.04 18:34) [7]
>
> > Григорьев Антон © (14.07.04 18:28) [3]
> >... его на то, чтобы он разобарлся, во-первых, как всё
> реализовано...
> >
>
> Антон, будто вы знаете как это реализовано? :))) Сейчас
> поясню мысль. :))) Очевидно, что здесь есть определенный
> compile time. Да есть. Но отсюда следует, чтобы разобраться
> нужно просмотреть компилятор :))) Врядли это кто-то делал?

Ой! А в реале мы вроде были на "ты"... ;)

Я сейчас не о том, как компилятор пытается оптимизировать код, а о желании Piter"а, чтобы использование заведомо некорректно инициализированного указателя обязательно приводило к AV. Тут никакой магии, всё просто.

← →
Тимохов © (2004-07-14 18:41) [12]

> Ой! А в реале мы вроде были на "ты"... ;)

блин, привычка. Не вввтвтвтвтвтвттттттты мне это говоришь. :))

> Я сейчас не о том, как компилятор пытается оптимизировать
> код, а о желании Piter"а, чтобы использование заведомо некорректно
> инициализированного указателя обязательно приводило к AV.
> Тут никакой магии, всё просто.

Это дело другое. Я ему уже посоветовал чистить память через freeinstance :)))))

← →
Тимохов © (2004-07-14 18:42) [13]

> блин, привычка. Не вввтвтвтвтвтвттттттты мне ПЕРВЫЙ это говоришь.
> :))

← →
Cobalt © (2004-07-14 19:16) [14]

2 Григорьев Антон ©
Насколько я понимаю, Piter хотел, что бы оператор is работал подобно обычому методу класса, но с Try-Finally (т.е. не падал при AV)
Типа такого:
Function IsClass1(c : TObject; T : TClass):boolean; begin try Result:=False; Result:= C is T; finally end; end;
Однако, не используя фишек типа if IsClass1(MyNode.Data,TEdit), необходимость в этом сомнительна.

← →
Тимохов © (2004-07-14 19:21) [15]

Главное, чего бы хотел питер - ИМЕННО получать ошибку, если объекта нет, а не так - то потухнет, то погаснет.

← →
Тимохов © (2004-07-14 19:32) [16]

> Cobalt © (14.07.04 19:16) [14]

вы это, того, finally c except спутали.

← →
Piter © (2004-07-14 21:35) [17]

Тимохов © (14.07.04 19:21) [15]
Главное, чего бы хотел питер - ИМЕННО получать ошибку, если объекта нет, а не так - то потухнет, то погаснет

ты прав. Больше всего не люблю неопределенность. Вот была в моем клиенте ошибка - возникала раз в неделю. И как ее блин ловить? Спасибо Nikkie - вместе додумались :)

В общем, народ, я что хотел сказать. Спасибо большое, что вы пытаетесь меня чему-то научить. Я это ценю и именно для этого нужен форум. Я несомненно сделал выводы из предыдущего топика, кое-что уяснил. И хочу поговорить вот о чем.

Я уже спрашивал Тимохова об одной вещи, но ветку ту закрыли. Попытаюсь еще раз.

Тимохов утверждает, что IS работает корректно, только неправильно описан в документации. Я же считаю его поведение некорректным и работать он должен так, как описано как раз в документации. Объясню почему.
Вот такой код есть:

var frm: TCustomForm; ... if frm is TForm;

Очевидно, что такой код НИЧЕМ не будет отличаться от проверки с помощью _IsClass, правильно? То есть, здесь употребление того и другого идентично.

Теперь подумаем - а когда поведение Is и _IsClass будет отличаться друг от друга? Вероятно, только в этом случае:

var frm: TForm; ... if frm is TForm then ...

Здесь _IsClass даст результат в зависимости от реального "содержимого" frm, а is даст всегда true (кроме случая nil). Тимохов, считает, что это правильно, что всегда будет true. Я же не вижу здесь ничего правильного. Какой смысл в данном случае вызвать IS? Ни-Ка-Ко-Го.

С таких же успехом можно написать:

var frm: TForm; ... if frm<>nil then ...

То есть, подводя итоги:
получается, что IS это тоже самое, что и вызов _IsClass. Кроме тех случаев, когда Is всегда возвращает True. Но какой смысл использовать оператор, если ты заранее знаешь, что он вернет true? Имхо, никакого. И не один программист, зная такое, не будет использовать.

Так что вот почему я считаю is неправильно реализованным оператором - потому что это оператор проверки. Он должен проверять. И в ситуациях, когда он ничего не проверяет - он не имеет смысла. Так зачем реализовывать ситуацию, когда он не имеет смысла? Почему бы не сделать так, чтобы он всегда проверял?

Просто я уверен, что от Is люди ждут такой же функциональности, что и от _IsClass. Это те, кто не знает как работает Is.
А те, кто знает - те просто не используют оператор Is, а используют inheritsfrom, как Тимохов. Ну и нафига тогда нужен этот Is? Чтобы вводить новичком в заблуждение?

← →
Cobalt © (2004-07-14 22:01) [18]

2 Piter ©
В целом, согласен с тобой, что было бы лучше, если оператор is проверял всегда (вызывал IsClass).

Однако, возвращаясь к реальности, приходится с этим смириться.
Или же попробовать растормошить людей с борландовских форумов, дабы через них попробовать добраться до разработчиков и упросить их изменить этот compiler magic (что, на мой взгляд, крайне маловероятно) и выложить на всеобщий доступ (?) обновлённую версию dcc32.exe

<offtop>Кстати, смотрел сейчас в Д4 у меня dcc32.exe на вкладке "Версия" отображается
Версия файла 3.0.0.0
Описание Delphi Pascal Compiler
--Доп. сведения----
| Имя элемента Значение
| Версия продукта 4.0
| Версия файла 4.0.0.0
|
</offtop>

← →
vuk © (2004-07-14 22:01) [19]

to Piter © (14.07.04 21:35) [17]:
>А те, кто знает - те просто не используют оператор Is, а
>используют inheritsfrom, как Тимохов.
Неправда Ваша, дяденька. Знаю как работает is и всегда использую только его. Проблем не имею. Что я делаю не так? :o)

← →
Cobalt © (2004-07-14 22:13) [20]

2 Piter ©
Причём, напирайте больше на тО, что проверка происходит не Runtime, a Compile-time.
И то, что производится она над Instance of object

← →
Piter © (2004-07-15 00:34) [21]

Григорьев Антон, не портите мне малину на Королевстве!!! Блина!!! Я специально закинул тот вопрос, чтобы проверить свои догадки. Не надо там отвечать!!!

← →
Cobalt © (2004-07-15 00:59) [22]

Миша, видишь ли, вопрос лишён практического применения, т.к. объявлять переменную некого типа, присваивать ей некое значение, а потом проверять, что она всё ещё того же типа, что и была.
Это... Ну, не делают так люди.
Обычно, объявляют класс-предок, и к нему потомков. И вот уже потом с ними можно и проверять их, и всё такое...

← →
jack128 © (2004-07-15 02:15) [23]

Если кого интересует мое ИМХО, то оно таково: is работает верно. То что в доке не описана эта особенность(то что VarOfSameType is TSameType генерирует только проверку на nil) это лишь мелкое упущение.

Миш, еще раз, как ты считаешь: приведение типа - это операция, проводимая полностью на свой страх и риск?

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

← →
Piter © (2004-07-15 02:42) [24]

jack128 © (15.07.04 2:15) [23]
приведение типа - это операция, проводимая полностью на свой страх и риск

да! Но это НЕ мешает компилятору проверить, понимаешь?

Электричество опасная вещь? Да! Но это не мешает делать защиту! А ведь можно было сказать - ты ведь знал что электричество опасная вещь? Ну и пеняй на себя, надо было ходить в резиновом костюме...

← →
jack128 © (2004-07-15 02:51) [25]

> да! Но это НЕ мешает компилятору проверить, понимаешь?

хе.
var
i: Integer;
begin
i := Integer(TEdit.Create(Self));
i := i + 15; // Что мешает компилятору проверить, что i - реально едит, а не число? Или же все таки компилятор не должен это проверять?
end;

← →
jack128 © (2004-07-15 02:53) [26]

только не надо говорить от технических трудностях, это понятно, но мы сейчас не об этом ;-)

← →
Piter © (2004-07-15 02:58) [27]

jack128 © (15.07.04 2:53) [26]

блин.... ты когда-нибудь спишь? :)

← →
Sergey Kaminski (2004-07-15 04:38) [28]

2 jack128 © (15.07.04 02:51) [25]

Хороший пример :) Как раз о разумных пределах и жалобах на то, что мол, я хотел компилятору мозги запудрить, а он и повёлся :)

2 Piter © (15.07.04 02:58) [27]
Я, как видишь, тоже никогда не сплю :))

← →
Sergey Kaminski (2004-07-15 04:40) [29]

и это есть "технические трудности" в реализации алгоритма засыпания :)

> jack128 © (15.07.04 02:51) [25]
var
i: Integer;
begin
i := Integer(TEdit.Create(Self));
i := i + 15; // Что мешает компилятору проверить, что i - реально едит, а не число? Или же все таки компилятор не должен это проверять?
end;

Пример, често скажу, отвратный :(
1) Где же тут проверка?
2) Integer и TEdit - разного рода сущности. TEdit и TButton - одного.

Моё мнение здесь такое: в нормальной программе не должно возникать ситуаций, когда можно заметить compiler magic оператора is. Но! Знать эту особенность компилятора надо - просто для общего развития.

← →
ИдиотЪ (2004-07-15 08:54) [32]

Вы все еще спорите ?

======
Дело было вечером ...

> [26] jack128 © (15.07.04 02:53)
> только не надо говорить от технических трудностях, это понятно,
> но мы сейчас не об этом ;-)

Это не технические трудности, это невозможно принципиально. Согласен с [30] Cobalt © (15.07.04 07:53).
Весьма странный пример, совсем не по теме.

Piter © (15.07.04 02:42) [24]
А ведь можно было сказать - ты ведь знал что электричество опасная вещь? Ну и пеняй на себя, надо было ходить в резиновом костюме...

Так что же ты перчатки не одел и обижаешься теперь на электричесво и продолжаешь кричать что оно бяка.

Удалено модератором
Примечание: r/o за мат

>Но это НЕ мешает компилятору проверить, понимаешь?
>Что мешает компилятору проверить, что i - реально едит, а не число?
- а теперь напишите мне реализаю TThread, где DWORD не будет приводиться к указателю на структуру, из которой берется instance объекта, либо к самому указатель на instance. И как компилятор узнает, что передано в Begin(Create)Thread? По вашему компилятор должен анализировать ВАШ код? Тогда пускай еще компилятор ищет ВАШИ логические ошибки, да и вообще пускай сам программы пишет...

З.Ы. Главное преимущество универсальных языков высокого уровня - это гибкость. И эта универсальность требует высокой квалификации программиста.
Если не хватает - пользуйтесь Basic-ом и будет вам щастье...

>Так-то оно так, но вот защиту от дурака не до конца доделали
- есть защита от дурака, а есть защита от идиота - вторая редко решается без помощи иммобилизации реципиента...

← →
Суслик (2004-07-15 13:39) [38]

Видел я эту ветку на королевстве.
Piter, уверяю - тебя там никто не понял, уж больно ты вопрос мудренО поставил. Понять то можно, но нужно знать предпосылки вопроса :))))

jack128 © (15.07.04 2:51) [25]
хе.
var
i: Integer;
begin
i := Integer(TEdit.Create(Self));
i := i + 15; // Что мешает компилятору проверить, что i - реально едит, а не число? Или же все таки компилятор не должен это проверять?
end;

неудачнейший пример. Почему здесь компилятор должен что-то проверять? Это ведь блин сложение? При сложение компилятор если и может что проверить - так это являются ли числами складываемые величины. А они являются числами по определению.

А оператором IS мы ПРОСИМ КОМПИЛЯТОР ПРОВЕРИТЬ. Это ведь разные вещи?

Я вовсе не в обиде на компилятор, если код:

TButton(SamePointer).Caption := "Ла-ла-ла".

приведет к ошибке. Потому что использовав такую конструкцию я ГОВОРЮ компилятору, что SamePointer - это экземпляр TButton. Он мне должен верить (я разработчик) и не обязан ничего проверять.

Но когда я употребляю IS - я ПРОШУ проверить. И тогда компилятор ДОЛЖЕН проверить.

← →
Суслик (2004-07-15 14:40) [40]

Ничего он не должен.
Целевую функцию is выполняет сполна.
Не надо умничать и все будет хорошо.

======================================
Тут одному ro дали. Может зря?
Вполне точно выразил мысль imho.

Оператор IS небезопасен для форм - продолжаем разговор Найти похожие ветки