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

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

Не многие поняли о чем речь... :)

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

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

А ведь вся эта писанина была бы не нужна при детальной типизации. Т.е., если бы для terminalId использовался диапазонный тип, а для type - перечислимый тип.

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

Ответ на »сообщение 1650« (Сергей Губанов)
___________________________

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

В стеке же сборщик в ББ работает консервативно и по целым тоже "привяжет" объект.

Не понял. А если у меня на стеке полно всяких целых чисел, значения которых случайно совпадают с адресами каких-то объектов, то эти объекты никогда не будут удалены?
Да, именно так. Сборка мусора на стеке в целях быстродействия в Оберонах ведется консервативно. Более того, существуют два режима сборки (константа Kernel.strictStackSweep). Если строгая сборка, то якорем является целое, указывающее на начало блока памяти объекта. При нестрогой сборке целое является якорем, даже если оно указывает на середину объекта. Для многопоточной среды приходится включать нестрогую сборку, т.к. один из потоков может выполнять процедуру с VAR-параметром, который указывает на одно из полей динамического объекта, и такой VAR-параметр мы также должны считать якорем, иначе последствия будут печальны :-)

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

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

Ответ на »сообщение 1638« (Владимир Лось)
___________________________
В том и дело, что через w сборщик мусора не проследит ссылку, т.к. она - целое, а не указатель. В этом и смысл слабой ссылки, что она не является якорем. Сборщик мусора зануляет все слабые ссылки, объекты которых не доступны по указателям.


Вот это мне и непонятно (может, я "туплю"): как сборщик мусора обнуляет все слабые ссылки, если он их не может проследить?
Речь идет о новом ядре АББ, в нем сборщик мусора - умеет это делать :-)
Я же уже писал - в ядре есть список всех созданных слабых ссылок и их адресов. После фазы маркировки доступности сборщик проверяет слабые ссылки на предмет промаркированности их целевых объектов. Те слабые ссылки, объекты которых более недоступны, зачищаются.

Ответ на »сообщение 1657« (Антон Григорьев)
___________________________

Только что коллега выкопал где-то в интернете: "Программа на С подобна гороскопу. По расположению звездочек в ней программист пытается определить что произойдет".


:)
Класс!

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

Ползучая гидра пробирается даже в девственно чистые ряды самого правильного языка всех времён и народов:о)))
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

Этот "Design by Contract Framework" был еще в MFC в прошлом веке, пользуйся - не хочу. Причем сама M$ пользовалась вовсю (чего не скажешь, например, о борланде в VCL).

Ладно. Смотрим пример использования и первое что видим:

  Status AddTerminal(int terminalId, int type)
  {
      // Checking Preconditions
      REQUIRE(terminalId < MAX_TERMINAL_ID);
      REQUIRE(type >= TERMINAL_TYPE_RANGE_MIN && type <= TERMINAL_TYPE_RANGE_MAX);

А ведь вся эта писанина была бы не нужна при детальной типизации. Т.е., если бы для terminalId использовался диапазонный тип, а для type - перечислимый тип.

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

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

>>Это просто компромисс, позволяющий сочетать надежность и эффективность.

А если у мена стеке мегабайтный массив?

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

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

Проблема в том, что в отличие от статических указателей (якорей) адреса указателей в стеке в этот момент неизвестны (их можно восстановить, но это слишком накладно).

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

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


В первоначальной ОС Оберон сборка мусора осуществлялась только между вызовами команд (т.е. при пустом стеке).

Что ж там за команды такие были, которые могли работать без сборки мусора?

Только что коллега выкопал где-то в интернете: "Программа на С подобна гороскопу. По расположению звездочек в ней программист пытается определить что произойдет".