DRAKON.SU

Добрый день.

При использовании ДРАКОН обратил внимание на то, что можно обойтись без веточных циклов при использовании выноса общего кода (общей ветки) в функции.
Или изменить предварительный код перед использованием общего кода.

Во вложении обработанный пример из книги.

Если веточный цикл не использовать, а использование веток всегда будет идти слева на право, то (на мой взгляд) можно при создании кода обойтись без GOTO. Т.е. выпрямлять силует до примитива и сплошняком описывать.

Вот получилось два вопроса

Готов рассмотреть примеры, где автор укажет невозможность отказа от ссылок на ветки, находящиеся слева, путем использования функций.

Мои предложения:

В блоке «Адрес» можно использовать только ссылку на следующую справа ветку.

И второе:
Общие ветки должны быть вынесены в функции.

Вот и нет оператора GOTO при формировании кода.
Весь код идет последовательно.

Вы правильно думаете... Есть и два ответа:

* viewtopic.php?p=70770#p70770;
* http://drakonografika.narod.ru/L3/algos ... #Doc-n322/

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

А, это за счёт введения флага? А может, надо найти здесь "сложность поведения", как делают "автоматчики"... и реализовать автомат? Или это исключительно так сделано из-за особенностей трансляции в данном редакторе?

Спасибо за ссылки.

Мое стремление отойти от GOTO связано с ориентацией на использование схем в связке с самым популярным в России транслятором (1С).

Цель - получение человекочитаемого кода при его автоматическом формировании из схемы, т.к. код с использованием многих GOTO просто не разобрать.
А мой код будут еще 10 человек смотреть и материть

Ну да. Там ведь будут сущности, которые не нужны на данном ("предметном") уровне рассмотрения вопроса. Это так же, как я сделал в статье насчёт маршрутов - есть те же соединители/разветвители как вершины схемы и есть то, что стоит за ними - контактирование маршрутов (которое можно реализовать через БП). А для удобства чтения и как вершины их можно не показывать - как и определено было в техноязыке... При изучении алгоритмов разобрали как следует, уяснили - и достаточно.