DRAKON.SU

Вот для воспитания культуры GOTO и убран. Valery Solovey выше всё пояснил.

При этом сам язык является воспитателем. А не дядя, который говорит что GOTO "плохое" и надо 10 раз подумать, прежде чем его использовать, а потом 20 раз подумать как использовать.

с точки зрения производительности: что работает быстрее - 10тыс GOTO или 10тыс CALL Procedure(...)...?
//
не вижу ничего зазорного в уместном использовании гото, другое дело что каждый "уместность" понимает по-своему и перлы типа
.
Goto M1; //переход к метке М1
.
не особо радуют...

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

бредятина полная имхо...
не вижу никакой ПРИНЦИПИАЛЬНОЙ разницы в конструкциях

Goto РасчетКФсучетомПоправки - которая адресует на 50 строк вниз по коду
и
CALL РасчетКФсучетомПоправки(); - которая адресует на 5000 строк вверх по коду программы.
.
все определяется уместностью использования Goto/
если мне гото позволит избежать 5и уровневого вложения Если и обойтисб 1 уровнем - я тут же заюзаю гото...
.
текст должен быть читабелен, понятен, и т.п. - какими методами это достигается - абсольтно все равно...
.
понятно что неиспользование гото на даннфй момент является дефакто стандартом, но отказываться от гото, там где он реально помогает - глупо...

> есть сложные абстракции с обозначенными границами, то GOTO-прыгание в них и из них,
- абсолютно согласен, возражений не имею.

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

Интересно. А не могли бы Вы объяснить поподробнее, каким образом GOTO используете вместо вызова процедур. С примером, если не сложно.

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

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

И вообще, мне всё чаще кажется, что "читабельностью" называют вовсе не удобочитаемость, а краткость записи. То есть, писабельность. Согласен, GOTO более писабелен.



Я имел в виду, что за неимением других средств структурирования, GOTO - в самый раз. В своё время я напрограммировался на ассемблере, помню хорошо

Спасибо, что Вы подумали и заформулировали.
А то заставить мозг насчет GOTO аргументированно диспутировать не удается.

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

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

Поскольку, увы, многие вообще не понимают, о чём тут речь (и какие пробелы надо закрывать), поясним на примере:
- до 3 класса школьники решают текстовые задачки на "нахождение..." путём рассуждений, "тыком". Нарабатываются какие-то приёмчики, аналогии, коллекции примерчиков, "искусство".
- потом детям объясняют, что такое уравнение - и все эти задачки становятся прозаичными и простыми. Никакого "искусства". Аккуратное владение аппаратом. И нажитые приёмчики и т.п. просто обесцениваются. "Уравнения" осваивать не хочется, нажитого жалко - крики про break-и как раз из той серии. Ну, не машет крыльями самолёт - не возникают break-и. Людям, владеющих аппаратом, он просто не нужен.

Касательно аппарата не постесняемся ещё раз указать ссылки, с чего можно начать:
http://oberoncore.ru/wiki/start, раздел алгоритмизации. А потом уж отправится читать указанные там книжки.

Честное слово, коллеги, ну сколько ж можно

Ну это элементарно -- вспомните Форт (некоторые реализации). Каждая процедура там передаёт управление следующей, фактически с помощью GOTO. Выполнилась одна форт-процедура, она передала управление следующей, та -- третьей и т.д.
За счёт этого на некоторых тестах получается значительный выигрыш по сравнению со стандартными CALL/RET.

PS. В ФП есть аналог этого -- Continuation passing style, немного по другому реализовано, но суть примерно такая же...
ЗЗЫ. Хотя нет, суть у CPS всё-таки совсем другая -- сохранение состояния по ходу работы такого конвейера...

Да, есть такая специфическая схема - концевой вызов процедур... Обычно такой стиль у новичков сразу "отбивают" (и правильно), поясняя, что не надо писать PROCEDURE A; BEGIN ... B END; PROCEDURE B; BEGIN .. C END;, а надо сделать декомпозицию сверху вниз: крупное действие составить из последовательности A; B; C.

Однако драконовские топологии при переводе в текст часто как раз отображаются на такой continuation. Тут можно это рассматривать как переход автомата. Указание, в какую ситуацию привело завершение текущего фрагмента, т.е. по какому маршруту продолжают развиваться события.

Тогда неплохо бы прямо в языке запретить писать функции-методы-процедуры размером более ___ строк. Или размер цикла - не более ___ операторов (поставьте свое любимое число).
Сам язык является воспитателем. В таком языке и goto не нужен.

Фанатики, блин... сумасшедшие

Чесслово...

1) стоимость этого запрета
2) выигрыш от этого запрета

Какая еще равноценность мнений?
И при чем тут, кто произносит мнение?

Кажется, предметная область отнюдь не гуманитарная - так что должно быть так: либо мнение соответствует действительности, либо - нет.

Вы не поверите: в гуманитарных областях та же фигня.
А по сути, налицо действительно расхождение во мнениях: что структурно, а что нет (как "пестро" и "не пестро" где-то у Гоголя).
Вот два разных подхода:

• структурное программирование - это программирование без goto (без break, без return - по вкусу)
• программы, разрабатываемые методом поэтапного уточнения, получаются структурными (там и правда потребность в goto почти не возникает)

Ну а с ассемблером что делать, без goto он посто не существует. Уничтожим как идейного врага, внедрим, так сказать, культурку? GOTO (в и его варианты) и есть на самом деле первая, изначальноя форма структурирования. А вовсе не нечто оному насмерть противоположное. Прародитель, замаскированный во всех этих while, if и тд.
Как же вы так, с папочкой?
Для программирования, как и для инженерии вообще, это не работает. Как и для искусства. Эти виды деятельности в результатах поливариантны. Одновременно истинно может быть так, а может и эдак.

Но отсюда не следует, что одновременно истинно может быть всё, что угодно.

А что есть "структурирование"? Если я описал структуру, обозначил евоные границы, а потом нагло перепрыгнул через них с помощью GOTO - это шшшто такое, как не повод для увольнения?