OberonCore

Для тех, кто "тык-мыкает", будет постоянный соблазн вкрутить лишний EXIT вместо думания над совокупностью условий.

Вот чего не понимаю... Тот же exit в виде Драконовской ветки никого вроде не напрягает и возражений не вызывает...

Получается "думание над совокупностью условий" vs. "нормальное визуальное представление"?

Эээ, в том-то и штука, что на плоскости получается не exit, а исход, по которому дальше идёт выполнение. А break-и в линейном тексте все ведут в одну точку. Если мы не можем сформулировать чётко условие на один исход - значит, плохо понимаем его смысл )
Если же ситуация такая, что действительно не хватает двумерности, многих исходов - то break не поможет, как мёртвому припарка. Вот и остаётся он для тыкальщиков ))

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

Лично я считаю вопрос этот предельно ясным - ситуации, про которые говорят "без досрочных выходов трудно", бывают - в управляющей логике особенно. Но break эти ситуации НЕ РЕШАЕТ. И вообще в рамках операторного языка их ничего не решит. А в большинстве случаев россказни про то, как "я не мог написать цикл без выхода, там такой цикл..." связаны просто с неумением циклы строить - если человек пишет что-то типовое, а не некий системный код автоматообразный.

В каких мало-мальски реалистичных языках (кроме О-07) есть цикл Дейкстры?

Имеется ввиду Why Python??

Есть ещё интересная цитата в его блоге C++ Considered Harmful:

Пример. В реализации одной структуры данных имеется список. В нём могут быть элементы с повторяющимися именами. Есть операция поиска i-го элемента с данным именем.

Пишем через простой линейный поиск:



Ради любопытства переписываем с циклом Дейкстры:


Сходимость тоже очевидна из наличия убывающих параметров.

А теперь внимание: сама собой случилась оптимизация, и условие i.name = name вычисляется только один раз. Классификация ситуаций идёт за счёт проверки на порядок более дешёвой i # NIL.
Т.е. ЦД даёт отличную свободу для манёвра

Там и без цикла Дейкстры присутствует свобода для манёвра.


Кстати, предполагается, что после цикла нужен IF?

Я инвертирую условие, и вы увидите, что ваш IF эквивалентен простому присваиванию:
Вместо переменной i можно сразу использовать it, тогда присваивание вообще можно удалить.

Если сразу использовать it, то да. Иначе, не эквивалентно: если num # 0, то нужного значения мы не нашли. Значит it не должен возвращать никакого объекта (если по условию задачи требуется строго num-ный указанный объект списка).

Ошибка: к моменту, когда num=0, i уже будет указывать на следующий элемент.

Контрпример: (c.items.name = name), (num = 0) -> (i = c.items).

Если при входе в процедуру num - это число элементов (i.name = name), которые нужно пропустить (т.е. num - это индекс, начинающийся с 0), тогда ошибки нет. Если num - это натуральный номер элемента, начинающийся с 1, то ошибка есть.

Ну, пусть Илья напишет, с чего начинается num - с 1 или 0.

Ах да, я забыл, что указатели при создании = NIL. То есть, достаточно просто присваивания.

Не, итерировать внешние переменную, по ссылке - нехорошо. Надо ж тоже понимать, что косвенность. Локальный параметр цикла может быть в регистре.
Для прогулки по списку, конечно, пофиг - там так и так разыменования, но зачем привыкать?
(Это как дельфисты попривыкали к return и многократному вызову IF Fun(..) ... THEN используем Fun(...) END)

C нуля num начинается...

А в цикле Валерия, даже при переделке, упрыгаем на следующий элемент. Т.е. нужно prev помнить... Или добавлять IF num > ... THEN it := it.next END. Так что не идёт. Плюс семантика разымыта как-то... Влияние внутреннего условия на остановку цикла через не очень осмысленную в этом случае переменную num.

Про локальную процедуру, как Сергей написал, - конечно, так и делается часто (Хотя функция с поб. эффектом - как-то неприятно...)

Но ЦД, по-моему, рулит

Да при чём тут вообще ЦД??? Была бы в КП операция "--", так этот поиск записывался бы в одну строчку:

while ((i # null) && ~((i.name == name) && (num-- == 0))) { i := i.next; }

В который раз убеждаюсь, что слухи о "рульности" ЦД сильно преувеличены: А был ли мальчик?

Просто хотел, чтобы это было упомянуто как техника оптимизации.

Это почему? Детерминированный вариант ЦД.

~ ( (i # NIL) & (i.name # name) ) <=> (i = NIL) OR (i.name = name)

Во второй ветке:

(i # NIL) & ( (i = NIL) OR (i.name = name) ) <=> FALSE OR (i # NIL) & (i.name = name) <=> (i # NIL) & (i.name = name)

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

ЦД позволяет вытащить все проверки, связанные с продолжением цикла, на один уровень.