Использование метки Опции

[Вячеслав Л.]

Такой вопрос: вщзможно ли использованием метки (label) заменить использование цикла? И если да то как это будет выглядеть?

[volvo]

Смотря как и где используется метка... Вообще-то менять нужно (ну не нужны метки + goto в программах, хоть что говорите), но вот на цикл ли - это вопрос... Может, if/else, может еще что - без кода сказать сложно.

[kosyak]

Всегда можно обойтись без меток и Goto. Лучше их не использовать хотябы потому что это очень сильно ухудшает читабельность кода.

[SKVOZNJAK]

Практически любой цикл можно заменить метками, и в FPC он будет прекрасно работать, отлаживаться и апгрейдиться, если без злоупотреблений, но:
1 Тебя побьют за такой код палками
2 Ты забудешь как записываются Repeat и While и не только.
3 Без понимания важности и полезности тебе сложнее будет изучать ООП.
4 При копипасте кода всегда нужно переписывать все метки и Goto.
5 После многих апгрейдов программа может приобрести структуру которая станет сложнее человеческого понимания (это не помешает улучшать её в дальнейшем). Для софта занимающегося жизнеобеспечением такой подход не катит...
6 Нужно уметь писать и без Goto.

Код

For A:=1 To 100 Do Begin
                                ........................                                  
                                ........................
                                End;

В FPC переменная A не может быть 64 битной, если конечно не исправили в новых версиях. Если вдруг понадобится её использовать - или переписывай код, или... С метками код может выглядеть вот так, и при необходимости выполнять не одно а несколько условий:

A:=0;
1:
Inc(A);
......................
......................
// A:=A+X; Попробуй такое вставить в цикл For на FPC
// If X=Y Then Goto 3;
If A>99 Then Goto 2;
Goto 1;
2:
3:

Сообщение отредактировано: SKVOZNJAK - 5.10.2009 0:48

[andriano]

Вообще-то GOTO с меткой может использоваться для организации совершенно различных конструкций:
1. Выполнения по условию (if).
2. Множественного ветвления (case).
3. Переборного цикла (for).
4. Цикла с условием, проверяемом перед его выполнением (while).
5. Цикла с условием, проверяемым в конце (repeat).
Применяя вместо безликого GOTO адекватный структурный оператор, ты лучше уясняешь себе смысл кода в процессе написания, что облегчает его отладку, а также существенно уменьшаешь время необходимое для того, чтобы понять его в дальнейшем (весьма вероятно, что ты и останешься единственным читателем собственного кода. Поверь, когда кода написано ДОСТАТОЧНО, ты будешь читать свой старый код так, как будто видишь его впервые. Т.е. не вспоминать, а разбираться заново).

[Вячеслав Л.]

Так что я понимаю, что goto'м лучше не увлекаться и по возможности заменять циклами, case'ом и. т. д. Буду стараться обходиться без goto. Спасибо за совет. Буду знать.

[TarasBer]

Буду стараться обходиться без goto.

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

[Вячеслав Л.]

Действительно, буду считать, что ты мне этого не говорил. Надо мне освоиться в паскале более менее, а там уже понятно станет, где нужна метка, а где нет. Буду стараться

[andriano]

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

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

Другими словами, оператор перехода плох не сам по себе, а исключительно тем, что является индикатором плохо спроектированного алгоритма.

[Lapp]

Другими словами, оператор перехода плох не сам по себе, а исключительно тем, что является индикатором плохо спроектированного алгоритма.

Соглашусь.

[TarasBer]

Другими словами, оператор перехода плох не сам по себе, а исключительно тем, что является индикатором плохо спроектированного алгоритма.

Давайте отменим Exit, Break, Continue?

[andriano]

Давайте отменим Exit, Break, Continue?

Мне без разницы, ни одним из них никогда не пользовался.
Кстати, Exit не является GOTO, это - аналог RETURN. Но тут также можно привести пример:

procedure MyProc;
begin
  ...
  тут некоторая достаточно длинная последовательность операторов
  ...
  DoSomething;
end;

Так вот, интересный факт: если ЯП не содержит аналогов Exit, то мы, не просматривая всего тела прцедуры, можем заключить, что при выходе из нее ВСЕГДА будет выполняться DoSomething. Увы, при наличии Exit нам для такой уверенности уже надо просмотреть весь текст процедуры, т.е. потребуется гораздо больше работы.
Так что вред от наличия в языке оператора Exit несомненен.
А вот польза сомнительна.

[SKVOZNJAK]

Мне без разницы, ни одним из них никогда не пользовался.
Кстати, Exit не является GOTO, это - аналог RETURN. Но тут также можно привести пример:

procedure MyProc;
begin
  ...
  тут некоторая достаточно длинная последовательность операторов
  ...
  DoSomething;
end;

Так вот, интересный факт: если ЯП не содержит аналогов Exit, то мы, не просматривая всего тела прцедуры, можем заключить, что при выходе из нее ВСЕГДА будет выполняться DoSomething. Увы, при наличии Exit нам для такой уверенности уже надо просмотреть весь текст процедуры, т.е. потребуется гораздо больше работы.
Так что вред от наличия в языке оператора Exit несомненен.
А вот польза сомнительна.

Лишь один частный случай который не даёт представления о всей реальной картине. Как такой вариант упорядоченного применения exit

procedure MyProc;
begin
  ...
  тут некоторая достаточно длинная последовательность операторов
...
If A=B then begin  //коменты, зачем и когда это нужно
                    DoSomething;
                    exit;
                    end;
If A=C then begin  //коменты, зачем и когда это нужно
                    тут некая последовательность нужных и полезных операторов
                    exit;
                    end;
end;

А можно и так:

procedure MyProc;
label 1, 2;
begin
  ...
  тут некоторая достаточно длинная последовательность операторов
GOTO 1;  //или A:=B; что больше нравится
...
...
GOTO 2; //или A:=C;
...
1: If A=B then begin  //коменты, зачем и когда это нужно
                    DoSomething;
                    exit;
                    end;
2: If A=C then begin  //коменты, зачем и когда это нужно
                    тут некая последовательность нужных и полезных операторов
                    exit;
                    end;
end;

Как видно, процедура отмаштабирована в большую сторону без добавления новых и существенного переписывания кода. "Лишние" процедуры в профессиональном коде принято прятать в других файлах (ещё найди в каких) что далеко не всегда улучшает читаемость программ но может немного уменьшить объём. Применение Goto, напротив позволяет уменьшить дробление кода на мелкие части и способствует частичной инкапсуляции данных без применения ООП. Выполняется ли при выходе процедура DoSomething; в общих чертах видно и без просмотра всего тела процедуры. Применение Goto позволяет масштабировать код не только в большую сторону но и в меньшую, но во втором случае размер кода и скомпилированной программы не уменьшится.

Сообщение отредактировано: SKVOZNJAK - 15.10.2009 0:31

[SKVOZNJAK]

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

Другими словами, оператор перехода плох не сам по себе, а исключительно тем, что является индикатором плохо спроектированного алгоритма.

Программы пишутся не только по проектам но и методом добавления новых возможностей работающему прототипу программы. Пока пишется проект и код, программа может морально устареть. В этом случае придётся переписывать проект, переделывать программу. С прототипом проще - автор одиночка может создать работающий прототип малого объёма и при необходимости в любой время добавить в него всё что понадобится. Не всегда известно, какие новые возможности потребуются программе через Х лет. GOTO поможет добавить новые возможности с минимальной переделкой уже написанного и отлаженного кода. К тому же этот замечательный оператор отлично применяется не только для выхода из циклов но и для входа
Наследие спектрум бейсика - куда от него убежишь.

Сообщение отредактировано: SKVOZNJAK - 15.10.2009 0:26

[volvo]

GOTO поможет добавить новые возможности с минимальной переделкой уже написанного и отлаженного кода. К тому же этот замечательный оператор отлично применяется не только для выхода из циклов но и для входа

Сквозняк, вот ты агитируешь за GoTo, а ты пробовал войти в цикл через этот самый GoTo при использовании языка, отличного от Паскаля или Бейсика? Или ты, пардон, собрался вечно сидеть только на Паскале? Тот же С++ тебя с большой степенью вероятности обломает, потому что там есть правила, как можно переходить по GoTo, а как нельзя... Ада - тоже обломает, там тоже есть правила, да еще и нет доступа к переменной цикла (если говорить о For). Привык к использованию goto - оказался привязан к одному/двум языкам, которые не проверяют возможных проблем... Кстати, а что делать с Java/JS, где ВООБЩЕ нет этой очень нужной и полезной для тебя инструкции? Ты их (равно как и все функциональные языки) сразу отсек? На них, значит, нельзя написать быстро модифицируемые программы, ага?

Так что, все остаемся в прошлом веке на Бейсиках и Турбо-Паскалях?

[SKVOZNJAK]

Я не агитирую всех и всегда использовать GOTO а лишь констатирую факт: есть сферы в которых оно полезно а есть такие в которых вредно: системы жизнеобеспечения и прочее в которых внезапное поумнения программ до уровня скайнет не допустимо. Где как кому лучше, то и надо применять, можно писать и без него, если эффективность не главное. Разве я против? Если я полностью откажусь от этого оператора, тогда должен навсегда забить на алгоритмы без него плохореализуемые. Пока к таким жертвам не готов.
Турбопаскаль уже не помню когда последний раз включал, да и не для программирования а для теста что работает и было это на прошлом проце. Про бейсик ты тоже зря вспомнил, та его разновидность что я назвал, не имеет к мелкомягким никакого отношения и применялась на восьмибитных компах. Ну не было бабла на персоналку а программировать хотелось Как я сейчас на бейсике сижу? Если только раз в несколько лет залезть поглубже в эмуль поковыряться. Жабой пока не пользовался, я с ней боролся - писал на FPC утилиту которая обрабатывает инфу с удалённой жабой. По этическим и практическим не уточняю деталей, но польза от неё есть, для меня. Насчёт Ада ничего не планирую, если вдруг понадобится, тогда и буду смотреть.

да еще и нет доступа к переменной цикла (если говорить о For)

А в FPC разве доступ есть? Но однако же работает - смотри мой первый пример. Говоришь о том что не применял и не тестил. В цикле меняется несколько операторов после чего с ним можно делать почти что угодно, до сих пор было так.
Ещё большой вопрос, с чем мне больше придётся иметь дело, с С или С++ Когда разберусь с этими языками, буду знать более точно, когда сам проверю. А с чужих слов можно узнать много чудесного, например: прямой доступ к элементу массива применять нельзя поскольку он аналогичен GOTO. При этих словах представляется картина: массив на 50 гигов, необходимо считать один байт из середины, и программа добросовестно последовательно считывает все байты с конца а юзер стучит ногой по системнику: опять винда заклинила.

Сообщение отредактировано: SKVOZNJAK - 15.10.2009 4:27

[andriano]

Я вместо этого:

procedure MyProc;
begin
If A=B then begin  //коменты, зачем и когда это нужно
                    DoSomething;
                    exit;
                    end;
If A=C then begin  //коменты, зачем и когда это нужно
                    тут некая последовательность нужных и полезных операторов
                    exit;
                    end;
end;

делаю так:

procedure MyProc;
begin
  case A of
    B: DoSomething;  //коменты, зачем и когда это нужно
    C: begin  //коменты, зачем и когда это нужно
            тут некая последовательность нужных и полезных операторов
    end;
  end; //case
end;

Откуда, собственно, ясно, что желание употребить Exit обусловлено неумением выбрать адекватную управляющую конструкцию.

Применение Goto позволяет масштабировать код не только в большую сторону но и в меньшую, но во втором случае размер кода и скомпилированной программы не уменьшится.

Я не понял, что здесь понимается под масштадированием.

Сообщение отредактировано: andriano - 15.10.2009 20:56

[SKVOZNJAK]

Откуда, собственно, ясно, что желание употребить Exit обусловлено неумением выбрать адекватную управляющую конструкцию.

А я давно его и не использую, goto гибче, а для аварийного выхода из программы можно и на 0 поделить, для отладки полезно.

Оператор case очень нужен и для goto

case A of
1: goto 1;
2: goto 2;
3: goto 3;
end;

Но в операторе case переменная A может быть не любого типа. Если вдруг понадобился неподдерживаемый тип, жди 100 лет пока в новом компиляторе добавят возможностей или переделывай структуру или воткни goto.

Если много раз апгрейдить эту процедуру

procedure MyProc;
begin
  case A of
    B: DoSomething;  //коменты, зачем и когда это нужно
    C: begin  //коменты, зачем и когда это нужно
            тут некая последовательность нужных и полезных операторов
    end;
  end; //case
end;

Однажды может понадобиться goto - чтобы перед case лишние операторы не выполнялись. Но лучше обходиться минимумом goto, от лишних вреда больше чем пользы, проверено.


Под масштабированием в большую сторону я понимал втыкание в программу больших и не очень кусков кода без существенной отладки. Представь некое усройство из квазиживого пластика. Стиральная машина или пылесос (или гибрид). Понадобилось приделать к нему возможности утюга. Находится нужное место, делается надрез, в него молоточком (goto) загоняется кусок пластика отрезанный от утюга. Как только утюг имплантирован, швы заровнялись, устройсройство стало больше в размерах и теперь не только пылесосит ковры но и утюжит. Так выглядит идея в идеале.
В консольных утилитах не нужно заморачиваться над интерфейсом - тот же квазиживой пластик непонятной формы. В какой-то момент ощущается нехватка некоторых опций командной строки, их нужно добавить, но существенно переделывать программу (а для этого придётся подробно её изучать) как-то не хочется, лень наверное Но может и просто не хватить знаний\времени на другие способы.

Под маштабированием в меньшую сторону понимал немного варварский метод. Берётся готовая работающая программа или библиотека и при помощи goto отсекается всё лишнее. Код никуда не исчезает, но он никогда не будет выполняться. Например, оконная система turbo vision на турбопаскале. В описании написано: изучай всё или ничего. Но можно изучить лишь часть, воткнуть в объект goto и использовать вместо неизученного или ненужного оригинального кода свой альтернативный. Причин для использования три: лень, эксперимент и необходимость.

[andriano]

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

Вот с этим полностью согласен.
От себя добавлю, что оптимальный минимум в данном случае равен нулю.

Под масштабированием в большую сторону я понимал втыкание в программу больших и не очень кусков кода без существенной отладки. Представь некое усройство из квазиживого пластика. Стиральная машина или пылесос (или гибрид). Понадобилось приделать к нему возможности утюга. Находится нужное место, делается надрез, в него молоточком (goto) загоняется кусок пластика отрезанный от утюга. Как только утюг имплантирован, швы заровнялись, устройсройство стало больше в размерах и теперь не только пылесосит ковры но и утюжит. Так выглядит идея в идеале.

Идея как идея. Но какое отношение к ней имеет GOTO?
Не нужен он здесь.

Под маштабированием в меньшую сторону понимал немного варварский метод. Берётся готовая работающая программа или библиотека и при помощи goto отсекается всё лишнее. Код никуда не исчезает, но он никогда не будет выполняться. Например, оконная система turbo vision на турбопаскале. В описании написано: изучай всё или ничего. Но можно изучить лишь часть, воткнуть в объект goto и использовать вместо неизученного или ненужного оригинального кода свой альтернативный. Причин для использования три: лень, эксперимент и необходимость.

Я в этом случае поступаю одним из трех способов.
1. Удаление фрагмента из программы.
2. "Комментирование" фрагмента.
3. Дополнительно ввожу логическую константу, которой присваиваю FALSE. Заключаю блок, оформленный в виде составного оператора, под условный оператор. Если мне вдруг понадобится исключенный кусок кода, переопределяю константу на TRUE.

[SKVOZNJAK]

Идея как идея. Но какое отношение к ней имеет GOTO?
Не нужен он здесь.

Нужен - он тот самый оператор из которого состоит множество других, даже ООП есть ни что иное как "резиновый" цикл на GOTO, убедился в этом когда лепил туда метки. Если вдруг понадобится строительный блок нестандартной конструкции, из GOTO его проще собрать и при необходимости перенастроить.

Я в этом случае поступаю одним из трех способов.
1. Удаление фрагмента из программы.
2. "Комментирование" фрагмента.
3. Дополнительно ввожу логическую константу, которой присваиваю FALSE. Заключаю блок, оформленный в виде составного оператора, под условный оператор. Если мне вдруг понадобится исключенный кусок кода, переопределяю константу на TRUE.

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

2. Чем больше фрагмент тем больше возни. Может плохо выглядеть - спутается с предыдущими коментами.

3. Если лишний код не одним куском, предстоит много возни и отладки. Предположим ты чуток подправил чужой исходник, затратил много сил чтобы только не использовать GOTO, а через время выйдет новая версия того же исходника, и опять всё сначала? Тоже самое что и "зачем нужен строительный кран если бригада гастарбайтеров может вручную затащить мешки с цементом на 10 этаж". Если есть возможность быстро строчить код, можно идти по пути наибольшего сопротивления не используя оператор который тебе не нравится.