OberonCore

Эта конструкция есть в языке Ада.

Не отмер.

Извиняюсь, щщас модератор отцепит от ветки и отправит мое сообщение в "Третий раз про выход из середины цикла"
Повтор кода. С возможностью ошибиться.

по сравнению с

Паттерн: прочитал, проверил, использовал (веня видел вицю - (С) Цезарь )

Хм...
Мне думается, что физики испытывают "кайф" от понимания сути вещей. Даже если это не соответствует некому формализму (работа у них такая, создавать новые формализмы по причине несоответствия старым). Арихитектура - вполне может являтся существом задуманного. Вполне...
И еще физики испытывают "кайф", когда заставили математиков адаптировать некие формализмы именно под суть вещей.
Например, ну аллергия у Вас на исключения, потому-что есть выход из структурной единицы "не там где положено"
Ну так измените свою теорию
Измените, все станет на свои места, и физик испытает "кайф"

В качестве развлечения: у меня есть точный тест, различающий физиков от математиков - доказательство теоремы Пифагора.
Если человек говорит: "Да, все правильно, потому-что так и есть на самом деле" - он физик.
А если начинает сомневаться в каждой строчке (их всего три) - он математик.
Хотите увидеть эти "три строчки"

Ну возможно, возможно...
Но, все-таки - сопротивляются
Тут, в принципе, и у меня барьер есть.
Читаю про инварианты и постусловия, все правильно, все хорошо. Один вопрос без ответа остается - нафига все это надо.
Примеры же даются элементарные !!! Где все прозрачно и без этих заморочек.
Вполне возможная реакция: "да это математики с ума сходят, им за это зарплату платят..."
Ну вот скажем, есть у нас на форуме примеры, где совершены ошибки. Не специально - а потому-что так устроена жизнь.

Можем мы применить формализм, чтобы с его помощью вскрыть эти ошибки
((кстати говоря - было бы очень интересно))
Если можем, тогда вопрос "нафига" - снимается, и последователей теории становится больше. Как бы.
Не знаю... Возможно следует выработать целый курс примеров с "ошибками, не видными первым взглядом"...
Для демонстрации Силы Формализма. Чтобы заткнуть рот любому Фоме Неверующему
Если она (Сила) есть, конечно же

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

Примеры неудачные. Это реализации автоматов. Я там написал ниже "Плюс обычные методы верификации программ здесь не работают."

А если человек говорит, что теорема Пифагора вовсе не теорема, а одна из аксиом евклидовой геометрии?

Давно же разжёвано. Действие перед циклом - добавочное. Оно выполняется на один раз больше, чем оборачивается цикл. Кроме того, его совпадение со сдвигом в цикле - чистая случайность.

http://oberoncore.ru/wiki/паттерны_циклов

Взаимно, Федор Васильевич.



А где нарушение структурности?
Недостатки синтаксической привязки RETURN к концу процедуры-функции.
1) Введение вспомогательной переменной. (Ср. рекурсивную функцию поиска/вставки в дерево в PIM и в PIO.)
1a) Это неэффективно (прежде всего для виртовских компиляторов; для оптимизирующих компиляторов это необязательно так).
1b) Это вызывает излишнюю умственную работу при чтении исходного текста функции. Результат функции в конкретной ветке алгоритма уже вычислен, но приходится читать дальше и гадать, не будет ли он "перевычислен" до конца функции.
2) Очевидный "синтаксический оверхед". Проще было бы понять возврат к паскалевскому варианту (вообще без RETURN).

Да, тут есть некая "вилка" между вопросом досрочного выхода и вопросом возврата значения.

В принципе, в практике я склоняюсь к тому, чтобы записать два-три RETURN, если они последние в процедуре (т.е. описание в стиле функции):

IF ... THEN
RETURN
ELSIF ... THEN
RETURN
END

При выделении жирностью RETURN, как это у нас принято, смотрится вполне как подобает кусочному определению функции.

А вот и тест на сформированность "структурного чтения" нарисовался

видите ли Вы принципиальную разницу между записью:

IF ... THEN RETURN A END;
IF ... THEN RETURN B END;
RETURN C

и
IF ... THEN RETURN A
ELSIF ... THEN RETURN B
ELSE RETURN C
END.

Т.е. коробит ли от первой из них?

Меня вот не коробит, потому что в первом случае - три разные структуры, выполняющие три разные задачи. Во втором случае, одна структура (IF ... ELSIF ... END) и я понимаю, что перед ней стоит какая-то своя задача

Но требование читабельности во втором случае исполняется чётче, потому что больше информации, в отличие от первого случая с набором команд (в первом случае надо следовать каким-то неявным соглашениям по последовательности команд, а эти соглашения в тексте не указаны).

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

Ну, можно же забыть RETURN. (Или это не по части структурности?)

В синтаксичности привязки уже есть некое благо. Вроде.

Можно сказать и так, что старый вариант -- пример преждевременной оптимизации.

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

Вот mr.Aleph цикл свой сделал -- наверняка на уровне непосредственно над циклом плохо программа структурирована.
Если бы у него был только жестокий ЦД, так ему автоматом пришлось бы бороться с плохой структурой своей программы, а не с отладкой дурацкого цикла.

Кстати, как насчет привязки LOOP+BREAK + множественный RETURN к IMPORT SYSTEM?
По-моему, если пренебречь усложнением компилятора, было бы самое то.

Мне думается, "структурное мышление" - это примерно как грамотность. Грамотный же человек о правилах не думает, он пишет грамотно. Так и со структурным мышлением. Илья прав - этому нужно УЧИТЬ! Как грамотности!
И отсюда: очевидно, должен быть период начале жизни "примата", когда структурное мышление осваивается самым оптимальным образом. Не успел во время этого периода освоить - дальше будут проблемы.

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

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

Теперь осталось только сократить эти два-три RETURN до одного

Еще бы статистику учесть: сколько функций имеют один RETURN, так сказать, естественным образом. По-моему, много.

Ни в коем случае не возражаю против принципов.
И не сомневаюсь, что Вы учите студентов правильно. В среднем.
(В среднем - потому что все люди - разные, и подходы как людям, так и к алгоритмам могут быть разные).
Тот тезаурус программирования, который предлагает Димыч, можно сравнить с алфавитом. Есть языки (естественные) которые используют мало букв, есть - много, а есть - так вообще пишут иероглифами. И ничего, когнитивность/креативность не сильно страдает?

Возможно, Ваше главное отличие от оппонентов в том, что для Вас век программистского искусства прошел, а для них век программистского ремесла еще не наступил. Ну или так: Вы пишете романы по сто тыщ буков, а они занимаются каллиграфией, до неузнаваемости меняя каждую буковку. Каждому свое

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


IMHO, трудно представить, что RETURN будет замечен внезапно, если вспомнить принятое в BB соглашение об оформлении исходного кода.

С той же вероятностью, с какой можно использовать неинициализированную переменную.
Обе ошибки легко находятся компилятором.


Не чувствуется уверенности.


В основном, согласен. (Кроме привязки EXIT и множественного RETURN именно к IMPORT SYSTEM. Все-таки назначение SYSTEM другое. Можно какую-нибудь другую "опцию" использовать.)