Ответ на »сообщение 1675« (Сергей Перовский)
___________________________
Просто "везде" следует воспринимать как гиперболу. ;-)

Ответ на »сообщение 1674« (Илья Ермаков)
___________________________
>>>Сборка мусора методом маркировки (не только в Обероне, везде) выполняется как атомарная операция, с заморозкой всех потоков приложения.
Тогда становится непонятно, как на Обероне пишут системы реального времени.
Ведь сборка мусора достаточно затратный алгоритм. Если на время его выполнения приложение останавливается, как гарантировать скорость реакции?

Ответ на »сообщение 1673« (Сергей Губанов)
___________________________
Сергей, сборка мусора методом маркировки (не только в Обероне, везде) выполняется как атомарная операция, с заморозкой всех потоков приложения.
Т.е. если весь граф объектов недоступен, то произойдет следующее:
1) Фаза маркировки по якорям - глобальным, стековым и регистровым.
2) Проверяется список слабых указателей. Если слабый указатель указывает на непромаркированный (т.е. недоступный объект), то его поле адреса обнуляется.
3) Все недоступные объекты удаляются (и весь ваш граф тоже).
1, 2, 3 выполняется как единая неразрывная операция.
В Актив Блэкбоксе есть и еще промежуточные фазы, связанные с подачей стоп-сигнала недоступным извне своего стека активным объектам, а затем принудительной их маркировке, т.к. удалить выполняющийся объект еще нельзя.

Ответ на »сообщение 1663« (Илья Ермаков)

Речь идет о новом ядре АББ, в нем сборщик мусора - умеет это делать :-)

А умеет ли он побеждать вот такую штуку:

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

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

Зовите меня просто - Снегурочка :) Пардон за оффтопик; что-то из слепленного образа отражено в чьих-то "самодельных" стихах: http://vcms.org.ru/article.php?sid=4446

Снегурочка, кто вы?! Уж очень знакомый стиль...

Ответ на »сообщение 1669« (Снегурочка)
___________________________

Неплохо также помнить, что Оберон, Оберон-2 и КП, хоть и имеют общие корни, но несколько разные языки, созданные для разных задач.

Если по-простому, то
1. Оберон изначально создавался для системного программирования (ОС Oberon)
2. Оберон-2 - для преподавания computer science (и ООП) в вузах
3. КП - для промышленного использования в сфере преимущественно заказных программных систем (embedded systems + real-time systems).

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

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

Пардон, что вмешиваюсь в Вашу дискуссию, но имело бы смысл учитывать следующее:

1. subrange и enumeration были исключены Виртом из "преОберона" (его экспериментов с Modula-компилятором) по целому ряду причин. Среди них: не самые важные вещи для написания ОС Oberon, упрощение компилятора, упрощение языка, упрощение run-time system.

2. Сами по себе с потребительской точки зрения (программиста-"прикладника") они нужные и важные, но цена их использования в Обероне, по мнению Вирта, слишком высока с позиций чистоты идей языка Оберон. А потому из языка они изъяты. У других может быть на сей счет свое личное мнение.

3. Валидация предусловий в действительности подразумевает проверку не одних лишь граничных значений для типов "входных" параметров, а куда более широкого спектра значений, которые отвечают жестким требованиям на начало исполнения данной единицы кода (процедуры, метода и т.п.). Они не отменяются введением subrange и enumeration.

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

На мой взгляд, малопродуктивны дискуссии вида:
A. Как нам разукрасить Оберон, т.е. "Чего бы такого добавить в Оберон, чего там нету".
B. Где там напортачил Вирт, т.е. "Чего он сделал/не сделал в языке такого, чего мне лично не нравится".

Лучше все-таки предварительно очерчивать очередную анализируемую сферу применения языка (кто для каких задач пытается его попользовать) и там смотреть, где язык имеет плюсы и минусы по отношению к другим языкам (признанным лидерам). Плюсы можно подчеркнуть, а минусы попытаться снивелировать за счет обсуждения идей инфраструктурных решений. Неплохо также помнить, что Оберон, Оберон-2 и КП, хоть и имеют общие корни, но несколько разные языки, созданные для разных задач.

Ответ на »сообщение 1667« (pepper)
___________________________
Не буду придумывать, сам всегда обожал субтипизацию :-)
В Обероне отвык, ну и, опять же, в системных задачах это не особо ощущается...

Ответ на »сообщение 1665« (Илья Ермаков)
___________________________


А если где-то до вызова в результате, например, сложения, произойдет выход за границу типа? Компилятор не отследит.
Контроль границ типов в рантайме дорог и обычно отключается в релизе, даже в таком языке, как Ada. Проверка на входе процедуры гораздо дешевле рантайм-контроля в каждом выражении.

1) Может быть дешевле, а может быть дороже, в зависимости от того, чего в конечном коде больше - операций со значением типа диапазон или количество передач между интерфейсами. Лично я считаю, что количество операций над таким типом будет меньше (самая частая операция над таким типом - это получение целочисленного значения, которая ничего не стоит и которую мы не учитываем).
2) В случае контроля операции, ошибка выявится там где она произошла, и не в момент передачи невалидного занчения в другое место (при том, что кто-то в "другом месте" не поленится/забудет сделать такую проверку прежде чем, например, передать ошибочное значение еще дальше от места ошибки).
3) В случае контроля операций над типом проверка сосредоточена в одном месте (в реализации типа), а не размазана по всему коду, который в интерфейсе имеет такой тип).
4) Если над типом требуется много операций, каждая из которых предполагает проверки диапазона, то всегда можно сделать такие операции над другим типом (без проверок), значение которого потом преобразовать в значение диапазнонного типа (выполнив проверку один раз).
5) С учетов всего сказанного, попробуй придумать хоть один более-менее реальный пример, где от присутствия в интерфейсе нетипизированных целочисленных типов был бы хоть какой-то реальный выигрыш.