Возврат из процедуры (функции)

← →
МитяЙ2 (2003-01-14 22:00) [0]

Доброго времени суток МАСТЕРА!

Помогите, если это в Ваших силах.

Проблема в следующем:

Есть обработчик события OnClickButton
в нем есть, вызов только ОДНОЙ процедуры X.

В этой процедуре X есть вызов процедуры X1,
в ней - вызов X2 и т.д. Причем каждая из
Xi-х может вызывать ЛЮБУЮ Xi!

Проблема:

Во многих местах процедур Xi есть
необходимость прекращения выполнения
самой Xi и передачи управления в OnClickButton
или в данном случае просто прекращение выполнения
всех вложенных процедур (в том числе X) и
"переход в режим ожидания" реакции от пользователя.

Подскажите как это сделать!

P.S. Пример неподходящего варианта:
Естественно при вызове функции exit в Xi-ой процедуре
происходит возврат на верхний уровень, т.е. на следующий
оператор в Xk-ой процедур, откуда вызвалась Xi-ая
процедура. А проблема в переходе сразу в X или
на уровень OnClickButton.

(пишу курсовичек по нисходящему анализатору для
написания копилятора)

Буду ООЧЧЕЕННЬЬ благодарен за помощь.
Митяй

← →
Митяй2 (2003-01-14 22:39) [1]

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

← →
Набережных С. (2003-01-14 23:05) [2]

function X2: boolean;

function X1: boolean;
begin
...
Result:=X2;
if not Result then Exit;
...
end;

procedure X;
begin
...
if not X1 then Exit;
...
end;

procedure ...OnClick;
begin
x;
end;

← →
Набережных С. (2003-01-14 23:06) [3]

Или просто Abort

← →
Юрий Зотов (2003-01-14 23:27) [4]

Можно и иначе:

procedure ...OnClick;
begin
try
x
except
... // Здесь можно проанализировать, откуда вывалились
end;
end;

После этого достаточно в любой последующий процедуре возбудить любое исключение.

← →
A2 (2003-01-14 23:27) [5]

В OnClick поставь блок "try ... except", а во всех остальных процедурах, если нужно прекратить выполнение, вызывай raise.

← →
OlDemon (2003-01-15 06:32) [6]

Я бы глобальный флажочек сделал. И по нему бы вываливался из всех функций.

← →
Digitman (2003-01-15 08:45) [7]

> пишу курсовичек по нисходящему анализатору для
> написания копилятора

К чему изобретать велосипед ? Возьми за основу готовый парсер YACC for Pascal. На вход ему подаешь скрипт-описание своего языка, на выходе получаешь текст Паскаль-модуля, осуществляющего парсинг и лексический анализ текста на твоем языке, который должен быть скомпилирован/интерпретирован.

Посмотри на filesearch.com или на Torry файл tp_lex_and_yacc.zip.
Там есть все, включая исходники YACC и примеры его использования

← →
A2 (2003-01-15 09:06) [8]

OlDemon>
> Я бы глобальный флажочек сделал. И по нему бы вываливался
> из всех функций.

Можно поинтересоваться, как это будет выглядеть на стеке вызовов функций?

← →
neXt (2003-01-15 09:16) [9]

> A2 (15.01.03 09:06)
Я подозреваю, OlDemon имеет в виду, что в каждой из Xi - функций после выхода из вложенных функций стоит проверка некого глобального флага, который любая из вызываемых функций может выставить в значение ВСЕ_НА_ВЫХОД. При наличие такого значения в флаге, любая из Xi - функций завершает работу, и управление возвращается по стеку в обратном порядке в OnClickButton.

:) Это очень дзенское решение! Примерно такое же, как проверка возвращаемого значения каждой Xi-функции. Истинные индейцы, могут попробовать... Но я бы рекомендовал бы, всё-таки использовать исключения.

← →
Набережных С. (2003-01-15 17:22) [10]

>neXt © (15.01.03 09:16)

Генерация и обработка исключения приводит к раскрутке стека и выливается в выполнение от 700-800 машинных инструкций. Анализ возвращаемого результата не стоит почти ничего, но кому это интересно "в наш век, когда космические корабли бороздят просторы вселенной"? ИМХО, защитные фреймы - мощный, но дорогой инструмент, пользоваться которым следует обдуманно и по назначению.
Вероятно, WinAPI писали сплошь "дзенские" программисты. Бедные, живут и не знают об этом...

← →
A2 (2003-01-15 20:08) [11]

> neXt
> Генерация и обработка исключения приводит к раскрутке стека
> и выливается в выполнение от 700-800 машинных инструкций.
> Анализ возвращаемого результата не стоит почти ничего

Дело не в количестве команд (700 800 действительно почти нничего не стоят), а в подходе к решению задачи, позволяющем избежать ошибок кодирования (при Exception) или почти наверняка посадить их штук этак несколько (при ЯВНОЙ проверке результата).

← →
Набережных С. (2003-01-15 20:14) [12]

>A2

Речь шла не о защите, а о способе принятия решения по результату работы функции

>700 800 действительно почти нничего не стоят)

Ну-ну

← →
Юрий Зотов (2003-01-15 20:17) [13]

Безусловно, решение через try-except НАМНОГО более ресурсоемко. Преимущество его, пожалуй, лишь в том, что оно позволяет без усложнения кода проанализировать результат цепочки вызовов и получить точку, в которой она была прервана (достаточно лишь возбуждать разные исключения, а в except расщепить их). Простой Exit этого не дает - придется вводить какие-то дополнительные переменные и усложнять код.

Если же анализ не требуется, то, конечно, Exit будет лучше.

← →
A2 (2003-01-15 20:35) [14]

> Если же анализ не требуется, то, конечно, Exit будет лучше.

Точнее, цепочка Exit"ов и проверок :-(

← →
A2 (2003-01-15 20:54) [15]

Кстати, мы совсем забыли, что вопрос касался нисходящего анализатора для компилятора. А в этот случае говорить о ресурсоемкости try-except не стоит: разница в скорости обработки исходного текста будет мизерная. В тоже время, исключения могут быть легко включены в логику грамматического разбора. Если в качестве типа результата взять не Boolean, а,например Integer, то в хорошо спроектированной программе оба эти варианта будут примерно равноценны.

← →
neXt (2003-01-16 10:37) [16]

> Набережных С. (15.01.03 17:22)

Так, интересно, а какое же "назначение" try-except как не экстренный выход по стеку вызовов к месту обработки исключительной ситуации? Вы в серьёз пологаете, что оптимизировать синтаксический анализатор нужно начинать с замены try-except на проверку ретвалов?
Тогда уж стоит отказаться от классов - всякой там vcl и Object Pascal, заодно. И вообще писать всё на C, а лучше на асме. Никаких тебе накладных расходов!
Принемать решение об отказе от какого-либо "удобства" программирования нужно только при двух условиях:
1. в голове тревожно бьётся мысль: "о, чёрт, где бы мне наиграть этих драгоценных 700-800 машинных инструкций!?"
2. Вы твёрдо знаете что отказ от "удобства" принесёт нужные плоды и не станит новым источником ошибок.

> Если в качестве типа результата взять не Boolean, а,например
> Integer, то в хорошо спроектированной программе оба эти
> варианта будут примерно равноценны.

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

← →
Набережных С. (2003-01-16 15:53) [17]

Я всерьез полагаю, что защитные фреймы нужно использовать в первую очередь для обработки нештатных ситуаций. При нормальном выполнении программы расходы на них мизерны и резко возрастают при обработке исключений. Но так как при грамотном проектировании вероятность исключения очень мала, то они и не влияют ни на что. По-моему, это очевидно. А 700-800 - примерная стартовая цифра, которая зависит от глубины стека и вложенности фреймов. Логический тип я привел только для демонстрации принципа и потому, что в вопросе речь не шла о детальном анализе. Заменим его на целый и получим любую необходимую функциональность, и это тоже мне казалось совершенно очевидным для любого программиста с опытом хотя-бы пол-года. Кроме того, я не говорил что вариант с try-except совершенно непригоден, у него, как и у других, есть свои достоинства и недостатки, которые нужно четко себе представлять. Впрочем, Вы, разумеется, можете оставаться при своем мнении, а я останусь при своем - с Вашего разрешения или без оного.

Возврат из процедуры (функции) Найти похожие ветки