| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Ошибка в delphi 7 [D7, WinXP]
Sicilla © (2004-11-17 18:34:00)Привет всем. Постваил себе delphi 7 взамен delphi 5. delphi 5 не удалял. И теперь ошибка: при отладке F7 например в переменной i значение 2, а кажет, что там 10 или -5. Хотя считает правильно в целом.
begin...end (2004-11-23 19:31:00) [41]
> [97] Defunct © (23.11.04 18:48)
Defunct, дело в том, что мне просто не нравятся голословные утверждения.
Вот Вы говорите в [81]:
> Моя цель была показать, что break не нужен, и что без break
> ошибки лучше видны. С чем я тоже успешно справился.
Надеюсь, это действительно Ваши слова, и я ничего не переврал?
Так вот - пожалуйста, покажите, ГДЕ в этой ветке Вы показали, что без Break ошибки лучше видны?
Ведь Вы ДО СИХ ПОР не привели кода, функционально соответствующего коду Gero [17]. Вместо этого Вы один за одним приводите варианты кода, в которых - ошибка на ошибке. На мой взгляд, это является прямым опровержением Вашего мнения. По крайней мере, для тех случаев, которые описываются в этой ветке.
> > Until <что-то> and (i<High(A));
> здесь была опечатка
А Вы можете наконец привести код, не содержащий опечаток?
И ещё - посмотрите, сколько человек согласно / не согласно (как я понял) с Вашим мнением о том, что "без break ошибки лучше видны".
Не согласны с этим утверждением (в алфавитном порядке):
1. Anatoly Podgoretsky (Мастер) [55]
2. begin...end [62]
3. Gero [8]
4. Ihor Osov'yak (Мастер) [50]
5. KSergey [85]
6. Palladin (Мастер) [31]
7. Verg (Мастер) [94]
8. Игорь Шевченко (Мастер) [30]
Согласны с этим утверждением:
1. Defunct
Вас это ни на какие мысли не наводит?
Defunct (2004-11-23 18:48:00) [42]> Да, т.к. повторю еще раз: он отличается функционально от оригинала. Не отличающийся я в вашем исполнении так и не увидел, увы... Задача же - показать функционально инедтичный код, а не код, примерно равный по функциональности, но работающий верно в других условиях. Это можно понять, наконец? При этом эти доп. условия по определению дожны быть указаны, т.к. являются неотъемлемой частью шаблона. Пусть и абстрактного.
Я вашу точку зрения понял. А вы мою?
> Хотя, а что же делать в немколько более сложном случае:
> for i := Low(A) to High(A) do
> begin
> if <проблема_1> then break;
> <код>
> if <проблема_2> then break;
> <код>
> if <что-то> then break
> end;
Помоему я уже написал, как быть в общем случае. Только вы приняли это решение, за не относящееся к теме:
while not BreakStatus do
begin
<код>;
<Процедура в которой рассматриваются все проблемы и условия пребывания>
end;
> А постоянно приводить функционально совершенно не идентичный код - это нормально по-вашему???!!
А упорно не хотеть понять мою точку зрения это нормально?
Читать сообщения не полностью тоже нормально?
> Про то, что для одного элемента выполнится цикл в любом случае - это как-то Defunct вообще игнорирует упорно до сих пор ;)
А if перед стартом цикла? Вы его конечно проигнорировали.
> Until <что-то> and (i<High(A));
здесь была опечатка
если вы посмотрите на время когда я постил примеры (5:00) утра, думаю можно быть более снисходительным.
Verg © (23.11.04 09:50) [94]
не уподобляйтейсь begin...end.
KSergey (2004-11-23 15:52:00) [43]> [95] begin...end © (23.11.04 15:39)
Да нет, я все же не о том.
Под "принципиально отличается" по структуре я имел в виду то, что if вынесен за пределы цикла! Т.е. в нем уже не может идти речь о проверке каких-либо элементов, тем более на каждой итерации. Изначальный же код выполнял if на каждой итерации. Налицо то, что код <ошибка> уже не применим, т.е. предлагаемый код не соответствует исходному по сути. Либо надо было оговаривать изменения в "абстракциях" (кусочках между <.. >).
Про то, что для одного элемента выполнится цикл в любом случае - это как-то Defunct вообще игнорирует упорно до сих пор ;)
begin...end (2004-11-23 15:39:00) [44]
> [93] KSergey © (23.11.04 09:44)
> То, что вы выделили - мелочь, по-моему. Код по структуре
> принципиально отличается. Пока не буду писать чем.
> I := 0;
> if not <ошибка> then
> Repeat
> <Код>
> inc(i);
> Until <что-то> and (i<High(A));
1. Если массив пуст, то проверяется выполнение условия <ошибка> для несуществующего элемента.
Прочие недостатки относятся к случаю <ошибка> = False:
2. Если массив состоит из одного элемента, то после первого прохода i > High(A), и цикл никогда не закончится (если, конечно, не учитывать его вылет из-за ошибки).
3. Независимо от количества элементов массива: если окажется, что <что-то> = False при любом i, то цикл никогда не закончится.
Кто больше?
> [94] Verg © (23.11.04 09:50)
> Да уж Open Source отдыхает...
Да, на всеобщее обозрение такой код лучше не выставлять, - слишком прозрачный.
Verg (2004-11-23 09:50:00) [45]
> [90] Defunct © (23.11.04 06:00)
> KSergey © (22.11.04 13:48) [89]
> > Либо см. [72], либо вот еще более простая ситуация: массив
> имеет нулевую длину. Законно?
>
> Понимаете, моей целью не было написать рабочий пример. Моей
> целью было написать абстрактный пример, который покажет
> суть того, как именно избавиться от break. Следовательно,
> меня абсолютно не волнуют ни опции компилятора, ни ситуации
> когда этот код не будет работать.
Это что, типа прозрачность в ущерб работоспособности?
А зачем тогда if not <ошибка> then?
Без этого if-а было бы еще прозрачнее.
Давайте прозрачный нерабочий код писать и сидеть наслаждаться "крысотой"!
Да уж Open Source отдыхает...
KSergey (2004-11-23 09:44:00) [46]> [92] begin...end © (23.11.04 09:16)
> Вот-вот... И, к тому же - опять неработающий...
> Until <что-то> and (i<High(A));
То, что вы выделили - мелочь, по-моему. Код по структуре принципиально отличается. Пока не буду писать чем.
begin...end (2004-11-23 09:16:00) [47]
> [91] KSergey © (23.11.04 08:36)
> > Теперь попробую с Repeat, здесь помоему еще прозрачнее:
>
> А постоянно приводить функционально совершенно не идентичный
> код - это нормально по-вашему???!!
Вот-вот... И, к тому же - опять неработающий...
> I := 0;
> if not <ошибка> then
> Repeat
> <Код>
> inc(i);
> Until <что-то> and (i<High(A));
Мда... Куда уж прозрачней...
KSergey (2004-11-23 08:36:00) [48]> Defunct © (23.11.04 06:00) [90]
> Вот теперь скажите, законно ли набрасываться на какой-то
> абстрактный кусочек кода, который просто показывает КАК
> можно избежать использования break?
Да, т.к. повторю еще раз: он отличается функционально от оригинала. Не отличающийся я в вашем исполнении так и не увидел, увы... Задача же - показать функционально инедтичный код, а не код, примерно равный по функциональности, но работающий верно в других условиях. Это можно понять, наконец? При этом эти доп. условия по определению дожны быть указаны, т.к. являются неотъемлемой частью шаблона. Пусть и абстрактного.
> Аналогичное по прозрачности:
Нууу.... Я бы так не сказал, хотя решить сие без голосования - наверное не выйдет ;) Впрочем, доверюсь вам.
Хотя, а что же делать в немколько более сложном случае:
for i := Low(A) to High(A) do
begin
if <проблема_1> then break;
<код>
if <проблема_2> then break;
<код>
if <что-то> then break
end;
Обрастать else if'ами? Нет уж, увольте. Хотя это, конечно же, опять дело вкуса, спорить тут, видимо, смысла нет.
> И вполне прозрачная логика, не находите?
Нахожу, только это не в тему совсем.
> Теперь попробую с Repeat, здесь помоему еще прозрачнее:
А постоянно приводить функционально совершенно не идентичный код - это нормально по-вашему???!!
Defunct (2004-11-23 06:00:00) [49]KSergey © (22.11.04 13:48) [89]
> Либо см. [72], либо вот еще более простая ситуация: массив имеет нулевую длину. Законно?
Понимаете, моей целью не было написать рабочий пример. Моей целью было написать абстрактный пример, который покажет суть того, как именно избавиться от break. Следовательно, меня абсолютно не волнуют ни опции компилятора, ни ситуации когда этот код не будет работать. Потому что я могу привести сколько угодно ситуаций, когда код Gero тоже не будет работать. Например:
Arr : Array[50..67] of TForm;
Вот теперь скажите, законно ли набрасываться на какой-то абстрактный кусочек кода, который просто показывает КАКможно избежать использования break?
> Хотелось бы увидеть или аналогичное по празрачности решение без for, либо...
for i := 0 to High(A) do
begin
if <ошибка> then break;
<код>
if <что-то> then break
end;
Аналогичное по прозрачности:
i := 0;
while (i<High(A)) and (not NeedToBreak) do
if <ошибка> then NeedToBreak := True else
begin
<код>
Inc(i);
if <что-то> then NeedToBreak := True
end;
Может вам с первого взгляда покажется, что кода написано больше. Зато логика цикла остается ровной. Условие выхода из цикла записано только в одном месте, и вы не будете гадать почему цикл был покинут или почему при отладке не попали на нужную вам строку.
Теперь попробую с Repeat, здесь помоему еще прозрачнее:
I := 0;
if not <ошибка> then
Repeat
<Код>
inc(i);
Until <что-то> and (i<High(A));
А в общем случае, лучше пользоваться правилом - "пиши проще" и избегать циклов с множеством условий выхода:
- разбивать сложный цикл на простые
- вынести как можно больше, часто ненужных, проверок из тела цикла
так что, например у меня, никогда бы не складывалась ситуация описанная Gero. Поскольку я никогда не использовал break, вообще не вижу ситуации когда бы последний был бы востребован.
вот сегодня написал, вполне рабочий код, и без всяких break.
хотя судя по возгласам некоторых, break в таких случаях применять просто необходимо:
while not ProgressForm.BreakStatus do
begin
StepForward;
<код>
<BreakStatus зависит от того нажмет ли пользователь на кнопу стоп, либо время в StepForward будет больше заданного>
end;
И вполне прозрачная логика, не находите?
> а личто я использую goto! ;) один раз правда
Goto - это инструмент других языков (Basic, Asm, fortran). Если вам довелось разок его применить, значит писали либо что-то низкоуровневое (имеется в виду системный уровень), либо наоборот - переходили с одного языка на другой.
begin...end © (22.11.04 10:59) [88]
> А вот теперь скажите, Сергей - стоит ли разговаривать серьёзно с человеком, упорно называющим свой неработающий код "рабочим"?
А вы умеете серьезно разговаривать?
Что-то не заметил.
KSergey (2004-11-22 13:48:00) [50]> Defunct © (19.11.04 15:35) [87]
> > Да при чем тут, блин, знак равенства?!! Неужели вы и вправду
> не видите проблем в своем коде и принципиальное отличие
> от приведенного с for?
> Я не вижу к чему вы прицепились в той одной строчке, абстрактного примера. см [81]
Плохо.
Либо см. [72], либо вот еще более простая ситуация: массив имеет нулевую длину. Законно? А тогда как быть с кодом из [70]?? При том, что цикл с for будет работать корректно.
Заметьте, я ни в коей мере покусаюсь на "абстрактность".
> > Да разве же кто-то спорит?
> Тогда будьте добры, укажите вашу цель этого разговора.
Хотелось бы увидеть или аналогичное по празрачности решение без for, либо... ну вы поняли ;)
А то, что в принципе без break обойтись можно - это безусловно, но цель-то наша, как мне видится, не в искуственных ограничениях религиозного толку, а в познании шаблонов прозрачного. лаконичного кода.
PS
а личто я использую goto! ;) один раз правда, но посоветовавшись с одним мужичком услышал от него верную, на мой взгляд, фразу: "если тебе удобнее и код здесь будет более прозрачен - так зачем себя насиловать и городить неестественные решения?"
begin...end (2004-11-22 10:59:00) [51]
> [85] KSergey © (19.11.04 08:24)
Сергей, оцените ситуацию объективно.
1. Defunct утверждает (см. [81]), что он успешно доказал: "без break ошибки лучше видны". Как мы видели, в процессе этого доказательства правильный код Gero (с Break, см. [17]) был превращён в неправильный код Defunct (без Break, см. [23]). В [23] НА 3 СТРОЧКИ КОДА ПРИХОДИТСЯ 2 ОШИБКИ. Правда, потом пропорция изменилась: теперь НА 3 СТРОЧКИ КОДА ПРИХОДИТСЯ 1 ОШИБКА . Всё равно - многовато. Таким образом, мы получили, по крайней мере, единичное опровержение утверждения "без break ошибки лучше видны".
2. В [70] Defunct приводит код, и характеризует его: "неабстрактным и рабочим , я его сделал еще до того как вы сегодня проснулись". В то же время очевидно, что ЭТОТ КОД ТОЖЕ НЕ РАБОТАЕТ . А Defunct, видимо, даже не потрудился выполнить его с включённой опцией Range Checking.
А вот теперь скажите, Сергей - стоит ли разговаривать серьёзно с человеком, упорно называющим свой неработающий код "рабочим"? И утверждающим, что он что-то "доказал", когда на самом деле он доказал обратное?
Defunct (2004-11-19 15:35:00) [52]> Да при чем тут, блин, знак равенства?!! Неужели вы и вправду не видите проблем в своем коде и принципиальное отличие от приведенного с for?
Я не вижу к чему вы прицепились в той одной строчке, абстрактного примера. см [81]
Зато проблему в for я вижу отчетливо - чтобы прервать цикл надо использоватать, с моей точки зрения левый, оператор break.
> Да разве же кто-то спорит?
Тогда будьте добры, укажите вашу цель этого разговора.
Потому что здается мне, ваша цель просто показать что я ошибся?
Fay (2004-11-19 09:33:00) [53]Все мётлы и веники - на помойку! Туда им дорога!!
Ах, как клёво подметать ломами да лопатами!!!
KSergey (2004-11-19 08:24:00) [54]Все же позволю себе написать. Хотя, понятно, вс еостанутся при своих имхах.
[63] Defunct © (18.11.04 16:41)
KSergey © (18.11.04 16:08) [61]
Это Gero так считает.
Нет, не он один. Я тоже так считаю.
[69] Defunct © (18.11.04 18:05)
2. Вы хотите порадоваться тем, что приперли меня к стенке знаком равенства.
Да при чем тут, блин, знак равенства?!! Неужели вы и вправду не видите проблем в своем коде и принципиальное отличие от приведенного с for? НЕ ВЕРЮ!
[70] Defunct © (18.11.04 18:15)
> begin...end ©
> Видите ли: если сделать на основе Вашего "абстрактного" кода "неабстрактный", то он тоже не будет работать.
Я вас огорчу, вот абстрактный код[23]:
while NoError(Arr[i]) and (i<High(Arr)) do
Begin
<Код>
end;
Сколько можно повторять, что он НЕ СООТВЕТСВУЕТ коду из [26]. Неужели ткнуть надо в чем именно? Да плевать на Inc и тонкости в операторе сравнения, это понятно что сделаете правильно. В вашем коде - ПРИНЦИПИАЛЬНая ошибка! Вернее не ошибка, а отличие. Ну посмотрите же внимательно, мне бы не хотелось тыкать... Впрочем, begin...end на нее уже указал, хотя я бы начал с другого варианта, ну да не важно. При этом, даже перестановка местами проверок - накладывает на разработчика заботу следить на опцией BoolEval. Зачем??
[28] Defunct © (18.11.04 00:28)
А я вам гарантирую, что без Break, Continue, Goto, Exit, Inline и прочее упомянутое можно запросто обойтись, причем всегда.
Да разве же кто-то спорит?
[69] Defunct © (18.11.04 18:05)
То что я хотел показать (без break можно обойтись всегда), я показал.
Безусловно, хотя тут вы уже лукавите.
> [69] Defunct © (18.11.04 18:05)
> Я ни разу в программах на Паскале и Delphi, за последние
> ~10 лет, не использовал ни break, ни goto, ни exit, а continue
> считал и считаю верхом алогизма (особенно если крутится
> вложенный цикл).
Во, вот тут наконец-то мы слышим правду. Безусловно, это личное дело каждого, но моя позиция противополжна. Хотя, конечно, это религия, тут спорить смысла нет.
И еще по поводу Exit.
Стандартный кусок:
if Проверка_1 then Выход;
Действия_1;
if Проверка_2 then Выход;
Действия_2;
if Проверка_3 then Выход;
Основные действия;
Ну Выходя написал условно, чтобы показать алгоритм. Смысл в том, что в случае выполнения проверок (на ошибки) дальше делать тут нечего. Да, можно вложить кучу if'ов. Но на мой взгляд - это ужас! Можно воспользоваться исключениями, как писали мастера выше. Но зачем изличне расходовать ресурсы?? Ведь очевидно, что Exit - легче, чем обработка исключений.
Defunct (2004-11-18 21:47:00) [55]begin...end © (18.11.04 18:58) [75]
Могу вам подыграть ;>
А еще я один раз написал в форуме:
(Sender.Handle as TControl).Left := ...
или что-то в этом духе.
Можете добавить в свой аресенал.
Defunct (2004-11-18 19:49:00) [56]Gero © (18.11.04 19:42) [82]
Как говорится, остались при своем imho.
Gero (2004-11-18 19:42:00) [57]
> А все стандартное легко запоминается и работа со стандартным
> сводится к механической работе.
Согласен. Break, Continue и пр. - вполне стандартные операторы.
Defunct (2004-11-18 19:35:00) [58]begin...end ©
> Их так просто заметить, что их не замечаете даже Вы - автор кода.
Ваша цель была найти ошибки, вы их нашли с чем вас и поздравляю.
Моя цель была показать, что break не нужен, и что без break ошибки лучше видны. С чем я тоже успешно справился.
Defunct (2004-11-18 19:30:00) [59]begin...end © (18.11.04 18:58) [75]
"плохой вечер хорошего дня"
> Неприятно, знаешь ли,
IMHO вы сами себя выставляете.
> Можете продолжать поливать меня грязью. Но лучше не надо - не позорьтесь.
Я вас ничем не поливал, помоему как раз наоборот.
PS: я на вас не обижаюсь. несдержанность это недуг.
Gero © (18.11.04 18:59) [76]
> Зачем вбивать себе в голову какие-либо ограничения?
Ограничения - сродни стандарту.
А все стандартное легко запоминается и работа со стандартным сводится к механической работе.
Например, не используя exit, мы вольны для отладки поставить точку останова на предпоследнюю строку процедуры и посмотреть значения переменных перед выходом из процедуры. Если же будет применен exit, то такой вариант отладки уже не пройдет.
Придется отлаживать нестандартно - ставить несколько точек останова на каждый exit.
В общем речь о том, чем меньше ветвлений, прыжков и т.п. тем прозрачнее алгоритм. Goto, Break, Exit, Cont., вносят дополнительные ветвления. А нужны ли нам эти ветвления если без них можно обойтись? Вот собсно об этом я и говорю.
begin...end (2004-11-18 19:20:00) [60]
> [74] Defunct © (18.11.04 18:51)
> если даже begin...end замечает ошибки в моем примере, то
> их действительно просто заметить
LOL. Их так просто заметить, что их незамечаете даже Вы - автор кода.
Указываешь Вам на ошибки, указываешь... а Вы всё о своём талдычите. ПривОдите свой же "неабстрактный код" в [73] с той же самой "легко замечаемой" ошибкой...
Можете продолжать поливать меня грязью. Но лучше не надо - не позорьтесь.
Засим дискуссию с Вами заканчиваю. Finish.
| |
Страницы: 