Ответ на »сообщение 1795« (pepper)
___________________________

Ответ на »сообщение 1794« (AVC)
___________________________


В принципе, так же, как это делает "посмертный отладчик".
(Т.е. опять-таки используем один механизм, а не плодим кучу механизм ad hoc.)
Берется frame pointer и т.д.


Картина маслом: "Физик-ядерщик берет frame pointer и раскручивает стэк".


Берусь предположить, что у и info21 никогда не возникала необходимость раскручивать стэк. А это именно в его сторону... :)

Ответ на »сообщение 1794« (AVC)
___________________________


В принципе, так же, как это делает "посмертный отладчик".
(Т.е. опять-таки используем один механизм, а не плодим кучу механизм ad hoc.)
Берется frame pointer и т.д.


Картина маслом: "Физик-ядерщик берет frame pointer и раскручивает стэк".


А что, в каких-то языках с поддержкой исключений есть временные затраты?
А как же?
Обратите внимание, что в Си++ поддержка механизма исключений обыкновенно требует специальной опции компиляторa.



Исключения в C++ раздувают бинарник в размере. О временных затратах я слышу первый раз от тебя. На популярных компиляторах ничего такого не наблюдается.

Ответ на »сообщение 1791« (pepper)
___________________________


Которая опять выходит за рамки языка. Обработчик найти мо метаинформации - это хорошо, а как стек раскручивать будем?

В принципе, так же, как это делает "посмертный отладчик".
(Т.е. опять-таки используем один механизм, а не плодим кучу механизм ad hoc.)
Берется frame pointer и т.д.

А что, в каких-то языках с поддержкой исключений есть временные затраты?

А как же?
Обратите внимание, что в Си++ поддержка механизма исключений обыкновенно требует специальной опции компиляторa.

Ответ на »сообщение 1792« (AVC)
___________________________


У всего свои плюсы и минусы, своя цена.


О да, цена еще нескольких ключевых слов в языке - чрезвычайно велика. Для кого?


Хочется деструкторов? Пожалуйста (Си++), но сразу минус сборка мусора и компонентность. Страшно удобно.


C++/CLI ;) Пока не побаловался с этим гибридом тоже думал, что деструкторы и GC несовместимы :) Кстати, модули там тоже есть (но сам лично не пользовался, так что про особенности не расскажу).


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


Что ты имеешь ввиду?


Интересно, а что именно неудобно в предложенном решении (в котором, кстати, используется возможность вложения процедур, отсутствующая в Си++)?

Объем писанины (за которой не видно кода) не устраивает. Кроме того, этот пример не решает проблему финализации (а для управления ресурсами она пригодилась бы).

Ответ на »сообщение 1790« (pepper)
___________________________

Ответ на »сообщение 1732« (AVC)
___________________________

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

Еще этот пример показывает, что без дополнительных языковых конструкций пользоваться "таким" неудобно (мягко говоря). Сравни с try/finally или деструкторами.

У всего свои плюсы и минусы, своя цена.
Хочется деструкторов? Пожалуйста (Си++), но сразу минус сборка мусора и компонентность. Страшно удобно.
Другой момент -- дополнительные накладные расходы на обеспечение возможности "отката", даже если "откат" не потребовался.
Интересно, а что именно неудобно в предложенном решении (в котором, кстати, используется возможность вложения процедур, отсутствующая в Си++)?

Ответ на »сообщение 1733« (AVC)
___________________________


Точнее, библиотечная процедура Exceptions.Raise находит ближайший обработчик исключений, пользуясь метапрограммными средствами обероновского (или иного) рантайма (например, райдерами, определенными в модуле Ref; для КП, наверное, можно использовать модуль Meta).
Плюсы такого решения:

• простота реализации (опять-таки :) );
  
  
  Которая опять выходит за рамки языка. Обработчик найти мо метаинформации - это хорошо, а как стек раскручивать будем?
  
  
  
• отсутствие дополнительных временных затрат (overhead) в случае, если исключение не возбуждается;
  
  
  А что, в каких-то языках с поддержкой исключений есть временные затраты?
  
  
  
• возможность использовать не только семантику завершения (в отличие от Си++ и Явы).
  

Если ты про семантику возобновления, то она не так востребована и легко эмулируется.

Ответ на »сообщение 1732« (AVC)
___________________________


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


Еще этот пример показывает, что без дополнительных языковых конструкций пользоваться "таким" неудобно (мягко говоря). Сравни с try/finally или деструкторами.

Ответ на »сообщение 1731« (AVC)
___________________________


В КП финализаторы поддерживаются на уровне языка:
PROCEDURE (p: ANYPTR) FINALIZE;
В языках со сборкой мусора деструкторов обычно нет.

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

Ответ на »сообщение 1730« (AVC)
___________________________

Ответ на »сообщение 1721« (pepper)
___________________________


как Оберон помогает освободить ресурсы (не память) при выходе из функции.


На самом деле выход из функции - частный случай (хотя и самый распространенный). Но передавать ресурс между функциями - тоже хочется.


Видимо, в вопросе содержится намек на деструкторы Си++ и т.п.


Никаких намеков не подразумевалось и механизма подобного деструкторам в C++ не ожидается. Но какой-то помощи от языка в деле управления ресурсами хочется.

Ответ на »сообщение 1743« (Владимир Лось)
___________________________

Коллеги!

А кто использовал GP CP?
Вопрос в следующем: имеем уже два места из которых поступает компилятор CP. Язык - понятно, австралийцы приводят OM-описание, значит, вроде как клянутся блюсти... А насколько "обвеска" разнится?

Framework BB, естественно, не поддерживается. С концепцией подсистем - глухо, на сколько я помню. Но все остальное точно по ГОСТу :) + в язык введены несущественные дополнения, для специфической работы с .NET (что всегда можно изолировать). Все возможности .NET (почти все) должны быть доступны. То же относится и к JVM. Но нужно посмотреть внимательнее.