Оператор 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]

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

← →
Cobalt © (2004-07-15 07:53) [30]

> 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 - одного.

← →
Григорьев Антон © (2004-07-15 08:45) [31]

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

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

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

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

← →
KSergey © (2004-07-15 09:20) [33]

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

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

← →
Anatoly Podgoretsky © (2004-07-15 09:46) [34]

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

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

← →
Vitaly © (2004-07-15 10:08) [35]

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

← →
Cobalt © (2004-07-15 12:28) [36]

2 Anatoly Podgoretsky ©
Так-то оно так, но вот защиту от дурака не до конца доделали ;-)

← →
han_malign © (2004-07-15 13:31) [37]

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

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

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

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

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

← →
Piter © (2004-07-15 14:33) [39]

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.

← →
Sandman25 © (2004-07-15 14:45) [41]

[40] Суслик (15.07.04 14:40)

ro дали не за содержание высказывания, а за форму

← →
Piter © (2004-07-15 14:46) [42]

Суслик (15.07.04 13:39) [38]
Видел я эту ветку на королевстве.
Piter, уверяю - тебя там никто не понял

ВСЕ ОНИ ПОНЯЛИ! И если бы не Григорьев Антон - никто бы в жизни не догадался.

Я вот почему завел ветку - все тут после моих рассказов начали кричать, что знают про особенность IS (про compiler magic). Но извините я в это не совсем верил. И решил убедиться - а правда что ли все знают как работает IS, а я не знал?

И задал вопрос на королевстве - там люди не глупее обитают, спорить, думаю, никто не будет.

Вот ветка - http://www.delphikingdom.com/asp/answer.asp?IDAnswer=23761

если бы не Антон с ссылкой на эту тему - никто правильного ответа не знает. Смотрите что пишет народ:

If Btn is TButton then
после чего компилятор начнет копаться в предках Btn ищя класс с названием TButton (для начала чисто теоретичеки представьте этот процесс, можно попробовать реализовать ... дальше видно будет).

это написал некий Johny B. Может, он там не мастер, но судя по всему - отвечает регулярно. Ну и что? Моя правда. Человек даже не подумал об compiler magic. У него сразу ассоциации с тем, что будет вызван IsClass!!! То есть, употребление Is он приравнивает к вызову IsClass.

И думаю никто бы не догадался.

где-то в JCL видел методы (процедуры), которые лезут в RTTI и меняют ссылку на класс обьекта

и он тоже даже не подумал об Is как о compiler magic. Он тоже ассоциирует употребление IS как вызов IsClass - поэтому единственным способом обмануть считает изменение класса объекта.

Если честно, я думаю, что до этой ветки и здесь многие не знали о таком свойстве Is. Просто не знали. Да, оно проявляется редко в хорошо написанных программах. Но такое свойство у Is есть. И тем более непонятно почему когда я рассказал о таком свойстве все стали кричать, что это понятно даже дебилам, хотя наверняка сами и не знали раньше о таком поведении Is.

Все вышеперечисленное мое ИМХО. Пожалуйста, не пишите в ветку на королевстве.
И так как эксперимент немного сорвался - я еще и в ФИДО планирую написать - надеюсь, там никого из нашенских не будет :) А если будет - то не отвечайте в ФИДО, если увидите такой вопрос, ок?
Мне просто интересно...

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

> ro дали не за содержание высказывания, а за форму

да понимаю я - это намек именно на содержание...

>Да, оно проявляется редко в хорошо написанных программах.

Можно 1 пример проявления в хорошо написанной программе?

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

> это написал некий Johny B. Может, он там не мастер, но
> судя по всему - отвечает регулярно

вы тоже регулярно отвечаете.

> Мне просто интересно...

Что вам интересно? Что вы не дурак? Так это и так ясно.
Что про особенности компилятора не все знают? Так это да. Я тоже не знал.
Что вы хотите себе доказать.

Нет, ну серьезно. Покажите мне пример хорошей программы с
Button: TButton и Button is TButton

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

Не покажет он ничего.
Успокоится только когда окажется что всё фидо, интернет, секретная сеть ФСБ и пентагона не знают про особенности is.

Button: TButton;

begin
repeat
Button := TButton(Pointer(Random(MAXINT)));
until Button is TButton;
Button.Click;
end;

Жалко только, что программа не очень хорошая. Но это в данном случае она не хорошая, потому что есть нормальный алгоритм, решающий данную задачу. Но ведь можно напрячь мозги и придумать такое задание, для которого действительно не будет решения или решение будет требовать слишком много памяти для хранения всех контролов.

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

> Жалко только, что программа не очень хорошая

Конечно не очень хорошая.

А что если tbutton скрывается в верхних 2гб? Не подумали?
Вот если от 0 до 4гб, тогда точно была бы хорошая программа - tbutton от нас нигде не сроектся.

:)

[50] Суслик (15.07.04 15:13)

А какая разница? ГСЧ все равно не гарантирует выпадание заданного числа N ни за какое время, а программный ГСЧ не гарантирует, что вообще возможно выпадение этого заданного числа в принципе. Так что в любом случае возможно зацикливание :)

Sandman25 © (15.07.04 14:49) [44]
Можно 1 пример проявления в хорошо написанной программе?

Ладно. В хорошо написанных программах такого не встречается. Ибо magic compiler работает только в случаях когда программист и сам будет знать о результате IS. Поэтому и не будет применять Is.
Но это те, кто знает

Суслик (15.07.04 15:00) [48]
Успокоится только когда окажется что всё фидо, интернет, секретная сеть ФСБ и пентагона не знают про особенности is.

мне твои наезды глубоко параллельны. Мне интересна одна догадка и я ее решаю по мере сил. Иронизировать можешь сколько хочешь. Только лучше не в этой ветке.

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

ну хочется человеку, чтоб ему памятник при жизни поставили, тут уж ничем не остановить
Я тоже когда-то нашел одну особенность, тоже немного пообсуждали и успокоились.
Опубликует книгу потом "Моя жизнь в поисках истины is"

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

> Piter © (15.07.04 15:29) [53]

В какой ветке я сам решу, ок?

Иронии и тени не был - это скокойная правда.
Вы все успокоится не можете, что так много времени потратили на такую ерунду. Ну что же - в будущем рациональнее будете.

Какая у вас догадка?! CPU под боком - ответ давно получен.

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

> ИдиотЪ (15.07.04 15:31) [54]
> ну хочется человеку, чтоб ему памятник при жизни поставили,
> тут уж ничем не остановить

Бинго

> А оператором IS мы ПРОСИМ КОМПИЛЯТОР ПРОВЕРИТЬ. Это ведь
> разные вещи?
>
> Я вовсе не в обиде на компилятор, если код:
>
> TButton(SamePointer).Caption := "Ла-ла-ла".
>
> приведет к ошибке. Потому что использовав такую конструкцию
> я ГОВОРЮ компилятору, что SamePointer - это экземпляр TButton.
> Он мне должен верить (я разработчик) и не обязан ничего
> проверять.

а вот так я говорю компилятору, что btn - это кнопка
var
btn: TButton; //И он мне должен верить (я разработчик) и не обязан ничего проверять.
;-)

> Это не технические трудности, это невозможно принципиально.
ну и что? Ну а представим, что это возможно тогда что? Тогда компилятор должен осуществлять такую проверку? Если считаешь, что да, тогда ответь на вопросы, поставленные> [37] han_malign © (15.07.04 13:31)

Удалено модератором
Примечание: Очередные нападки, в том числе и на модераторов

[58] Piter © (15.07.04 18:15)
Нет бы хоть проявить толику уважения к человеку, который сказал для вас какую-то новую вещь...

Уважаю. Но мне не менее параллельно о семантике IS равно как и тебе мнение там каких то людей, уважающих модераторов или мастеров.

> Факт в том, что это многие не знали, как тот же Суслик.

Ну и что?

> А Вы, видимо, поставили для себя задачу убедить меня, что
> я ламак

Как вам кто-то говорил - вы точно параноик :)))

> чуть попытался задать неочевидный вопрос

Не надо говорить неправду :)))
Вспомните самый первый вопрос? Он был неочевиден? Наверное только вам. :))) Не перетягивайте. И Григорьев и Тимохов заметили вам о том, что считают один из открытых вами фактов (несоответсвие описание реализации) интересным. Что же вам еще надо. Чтобы о вас статью написали в правде? :)))

В качестве вывода :)))
Как вы говорите "интересная вешь" получается: облажался в невинном месте, выяснил много нового (за это респект), почему облажался, и страсть как хочет узнать а могли ли другие (теоретически) так облажаться. И мне кажется начинает успокаиваться узнав о том, что могли, т.к. не знали факта отрытого им.

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

vuk, в частности, а также многие другие очень граммотно это подчеркнули.

----------------------------
За "дефекацию" и весь пост (твой) могут почикать.
Не кипятись :)))

> А Вы, видимо, поставили для себя задачу убедить меня, что
> я ламак.
Да? Где это я такое говорил?

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