Re[60]: Нужна ли Оберон-ОС защита памяти?
От: _vovin http://www.pragmatic-architect.com
Дата: 28.01.05 09:32
Оценка: 79 (5) +1 :))) :))) :))
Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Сергей Губанов, Вы писали:


СГ>>Здравствуйте, Курилка, Вы писали:


К>>> Ага, а как же пример с десктопом — он знает об окне, но десктоп не удаляется...


СГ>>Значит сделано по умному.


К>Вот и давайте будем поклоняться умному Вирту!

К>Мы не знаем как оно работает, но ведь великая вещь!

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/18422
http://c2.com/cgi/wiki?HeInventedTheTerm

There is a story (which I quote from memory, may not have all the details right) about a talk that Niklaus Wirth gave at Apple Computer about Oberon. He was some way into the talk when a chap at the back stood up and said, "So you say that Oberon doesn't have inheritance?"
Wirth, "No, that's right"
"And it doesn't have..." (insert here various things that Ruby and Smalltalk have, but Oberon doesn't).
Wirth agreed.
"Then how can you say that it is an Object-Oriented Language?"
To which Wirth replies, "Well, who can say what is, and what isn't, an OO language?"
Chap says, "I can, I'm Alan Kay, and I invented the term"

Re[7]: Нужна ли Оберон-ОС защита памяти?
От: WolfHound  
Дата: 24.01.05 15:38
Оценка: +1 :))) :))) :))
Здравствуйте, Трурль, Вы писали:

Т>Результаты 1 — 10 из примерно 14 600 для porshe 911.

Т>Результаты 1 — 10 из примерно 2 940 000 для volkswagen golf.
Результаты 1 — 10 из примерно 3 760 для горбатый запорожец
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: Нужна ли Оберон-ОС защита памяти?
От: Зверёк Харьковский  
Дата: 25.01.05 22:52
Оценка: 35 (6) +2
Здравствуйте, AVC, Вы писали:

AVC>>Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как...

AVC>...Зверек Харьковский со своей статьей "C++ulture".
С одной стороны. А с другой — это единственная разумная формулировка для теплого отношения к языку программирования.
Любить некий язык можно только потому, что ты его любишь. По прагматическим соображениям его можно использовать, считать приемлемым для некоторого круга задач — а любовь чувство иррациональное.
Поэтому с той статьей никто и не спорил (практически. А те, кто спорили, выглядели странно)

Ну и почти по теме ветки (чтоб совсем в оффтоп не скатываться): хотел выразить свой респект господину AVC (даже несмотря на то, что он меня слегка обгадил ) — в отличие от топиков СГ (особенно в Первую Оберонову Войну) — они заставляют прислушиваться. Поскольку звучат разумно и доказательно — в отличие от некоторых присутствующих, чьи топики явно несут в себе память участия в Антиобероновом Сопротивлении. Заметьте, что "в прошлый раз" именно Обероново Воинство выглядело в стиле "ЛапыПрочьОтКрутейшегоЯзыка, НеХватаетОпытаНеСуйтесь, ИдитеЧитайтеFМануал" и т.д. — их просто не хотелось слушать. А в этот раз почему-то флаг "ИдитеНафик" перехватили антиобероновцы. И это печально.
сам слушаю и вам рекомендую: Чиж&Co — Менуэт
FAQ — це мiй ай-кью!
Re[20]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 16.02.05 12:19
Оценка: +2 :))) :)))
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Как интересно в Си/Си++/Java/C# работают с битами? Наверное там битовые операции применяют прямо к числам? Вот несчастные программисты, как они там мучаются — ведь в Си/Си++/Java/C# множество битов и числа — это одно и тоже, хотя спроси любого математика так он ответит, что число — это одна математическая абстракция (теория чисел), а множество — совсем другая (теория множеств).


Вот ты для разнообразия и спроси математика, какими способами можно представить множества...
Навскидку:
— предикат как чёрный ящик
— предикат как формула
— булев вектор (элементы универсума пронумерованы)
— упорядоченная последовательность (над элементами определено отношение порядка)
— неупорядоченная последовательность (над элементами определено отношение эквивалентности)

Паскалевское (sic! ещё паскалевское, а не обероновское) множество — это булев вектор размерности не более чем 256.

А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.
К примеру, матрицы. Не просто "двумерный массив", а именно матрицы со всей их алгеброй. Почему в Обероне нет матричной алгебры?
А между прочим, она уже давным-давно реализована на уровне языка: смотри APL, MatLab.
Я даже не прошу тензорную алгебру, бог с ней, она не часто нужна, да и размерности там офигительные. Хотя в минимальном виде (аффиноры) можно было бы.
А куда делись столь нужные 3D-моделистам кватернионы?
И после этого ты ещё осмеливаешься хвалить Оберон?
Перекуём баги на фичи!
Re[54]: Эксперимент
От: Sergey Россия  
Дата: 27.01.05 15:41
Оценка: +7
Hello, Сергей!
You wrote on Thu, 27 Jan 2005 15:19:20 GMT:

СГ> Ну, что, съели? Еще возникать будете? Может еще какой-нибудь

СГ> эксперимент поставим?

Отсюда следует только то, что Оберон выгружает модули совсем не так, как ты
рассказывал, и одним GС там дело не ограничивается. Т.е., ты сам не знаешь,
как он работает

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[50]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 09.02.05 23:18
Оценка: 57 (2) +1 :)))
Здравствуйте, Cyberax, Вы писали:

>> И я так думаю.

>> Одномерный (гибкий) массив — базовая конструкция.
>> А теперь я хочу получить массив массивов.
C>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
C>разных условий лучше подходят разные варианты.

Я не против других вариантов.
Но Вы все же лукавите. Я же ясно написал — массив массивов, причем мы договорились называть массивом базовую конструкцию языка. Так что вариант, конечно, в данном случае только один.

>> Т.к. массив — базовая конструкция, то язык должен это позволять.

>> А Си++ — не позволяет.
C>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

Ах, увы... впрочем, что это я?
А что, массива — просто мас-си-ва — сегодня в продаже нет?

C>А вот сделать разреженную матрицу на Обероне красиво не получится.

C>Вместо оператора индекса будет всякие функции типа GetElement().

Да, блин, что-то некрасиво получается.
GetElement(), уродство какое-то...

>>>> Об этом я и говорю.

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

Что-то мне это напоминает ежика:

Сильный-то я сильный. Но легкий.

А процесс кодирования на Си++ (с "отключаемой сильной типизацией") напоминает еще одного ежика:

"Я не пукну. Я не пукну."
Пук!
"Это не я. Это не я."



>>> Только Си — простой, маленький и честный язык.

>>> А Си++ пытается усидеть на всех стульях сразу.
> C>И у него это получается. Не идеально, конечно, но получается.
>> *Пока*.
>> А когда выйдет новый стандарт?
C>Недавно, кажется вышел. Добавили стандартный ABI.

Тут я "зарапортовался". Получилась двусмысленность. Как будто я с нетерпением ожидаю еще одного стандарта Си++, от которого мои "шелковистые волосы" прорастут уж в совсем неожиданных местах.
Я хотел сказать, что пока еще Си++ удается усидеть на нескольких стульях.
Но вот он еще прибавит в весе, и стулья его уже не выдержат, как в фильме "Любовь зла..."
Страуструп еще полон сил и очередных творческих планов. Твердо обещает GC для плюсов и мать Кузьмы их противникам.
Нет, ну как нарочно! Такое чувство, что человек решил жизнь положить, чтобы доказать, что все можно делать через задницу. Сначала непреклонная борьба за совместимость с Си, указатели, имеющие видимость типа лишь до первого его приведения, и священную адресную арифметику. А теперь распухшие от богатства идей компиляторы Си++ будут бегать (наверное, в оздоровительных целях) по всему коду и собирать эти указатели сачком?!
Живо представляю себе шутки GC в плюсах (да еще при совместимости с Си):

Вот Вася проснется, а голова-то в тумбочке!

Не знаю, что и сказать. То ли "верной дорогой...", то ли "туда и дорога..."

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[48]: Нужна ли Оберон-ОС защита памяти?
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.01.05 09:03
Оценка: 4 (2) +4
Здравствуйте, Sergey, Вы писали:

S>Он не ненужный, он с ошибкой — взбесился и начал немерянно отжирать память.

S>И другие объекты имеют указатели, показывающие на этот объект и его части.
S>Что произойдет с ними, если убить дефектный объект?
Фанаты Оберона почему-то никак не хотят разговаривать о поведении Оберона при принудительном завершении процесса (активного объекта).
Попробую порассуждать за них. Предположим, что нам удалось инициировать возникновение исключения "OopsActiveObjectDead" внутри потока исполнения.
Нормальная среда с поддержкой исключений в таком случае начинает раскручивать стек. В управляемой среде это, в частности, означает, что объекты, "спрятанные" от GC ссылками из этого стека, "выйдут из тени". При том, разумеется, условии, что никаких других ссылок на них нет. Так что в случае того самого бесконечного списка, "зацепленного" за локальную переменную, при возникновении исключения все объекты в этом списке автоматически попадут под нож GC. Кстати, не обязательно инициировать исключение внешними средствами — оно может возникнуть само, если среда поддерживает квоты: очередной NEW просто выбросит QuotaExceeded.
Однако, остаются еще проблемы:
1. Что делать, если активный объект перехватывает исключения? (Возможное решение: не поддерживать исключения; механизм раскрутки стека применять только в одном случае — убийство активного объекта. Точно так же, как винда зачищает хэндлы, открытые убитым процессом.)
2. Что делать с теми, кто держит в руках ссылку на активный объект, который внезапно умер? (Возможное решение: статус объекта становится Dead, любой метод приводит к InvalidOperationException. Плохо: его поля все еще могут держать ссылки на мусор, не давая закончить очистку.)
3. Что делать с теми, кто держит в руках ссылку на "наследство" умершего активного объекта? Если он успел передать наружу ссылку на свой бесконечный список, то убийство за превышение квоты память в систему не вернет.
4. Как определять квоты? Поскольку память в системе — общая, то невозможно провести границу принадлежности объектов активным объектам. В винде это не так — размер выделенной физической и виртуальной памяти однозначно известен.

В общем, если у AOS нет ответов на эти вопросы, то в качестве ОС общего назначения она не годится. Из-за отсутствия приемлемой изоляции между объектами. Даже если не принимать во внимание низкоуровневый стуфф типа драйверов, прямых адресов и т.п.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: Нужна ли Оберон-ОС защита памяти?
От: WolfHound  
Дата: 25.01.05 13:43
Оценка: 1 (1) +4 :)
Здравствуйте, AVC, Вы писали:

AVC>Логика учит : чтобы утверждать, что типизация в Си++ сильнее, чем в Обероне, надо хорошо представлять себе не только Си++, но и Оберон.

А что его представлять? Примитивный язык в которм коллекции либо полиморфные либо копипастные. Те либо дублирование кода, а это дублирование ошибок... либо все проверки в рантайме медленно и не надежно.
А то что нет злых кастов на уровне языка так это дело поправляется (псевдо)модулем SYSTEM...
Да и без этого можно систему завалить. Делаем запутаный граф объектов которой в какомто левом модуле(который SYSTEM не использует)цепляется за глобальную переменную и привет... ГЦ умер...

AVC>Зря Вы за это "уцепились". Получается как в известной пословице про "услышанный звон".

AVC>В указанном Вами месте я отвечал на вопрос, если в Обероне в принципе средства низкоуровневого программирования.
Возможность есть. А заначит есть возможность напакостить.
AVC>Но дело в том, что в Обероне средства низкоуровневого программирования отделены от основного языка.
Но это не мешает их использовать.
AVC>Необходимо использовать (псевдо)модуль SYSTEM, чего нельзя скрыть, и что может быть и запрещено, если это потребуется для безопасности системы.
AVC>А в Си/Си++ — это не так.
В С++ тоже можно административно запретить использовать некоторые конструкции. И в чем разница?
AVC>Там без приведения типов — никуда.
А! То-то у меня в последнем проекте ни одного небыло. (кроме dynamic_cast'ов)
AVC>Просто Вы пытаетесь спрятать их подальше (в boost::function, к примеру), чтобы глаза не мозолили.
Вот там они и сидят. В принципе они только и нужны для написания библиотек низкого уровня. Короче можешь считать что они спрятаны в нутрь компилятора.
Кстати а как на счет ошибок в компиляторе оберона?...
AVC>Мало того, что это не решает проблему в корне, но еще и ухудшает читабельность.
Ты это можешь расказывать тем кто на С++ не писал.

AVC>С новыми наворотами boost Си++ уже не три года изучать надо, как по средней статистике, а еще больше.

А! Ну-ну. Если человек не совсем пробка он у меня через полгода на С++ с STL и boost'ом писать будет.
А пробка и на обероне таких дров наломает что мало не покажется.

AVC>Я уже заметил, что у программистов на Си++ мышление повернуто несколько в садистскую плоскость: кого/что убить... в кандалы... в Сибирь...

В данный момент я программист на C#. И вобще я могу писать на чем угодно. Просто раздаражают люди которые пытаются навязать какуюто поделку в качестве панацеи. Вот и получаются резкии фразы.

AVC>Только все эти заклинания слабо им помогают...

Мне они не нужны. У меня проблем нет.

AVC>Наверное, Канаде и Англии плохо приходится, если у них такие ПРОБЛЕМЫ!

Не знаю. Я там небыл. Хотя про Канадских программистов расказывают такое... что они якобы хуже Индусов...
Кстати ты не ответил как там с BrainFack'ом?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Нужна ли Оберон-ОС защита памяти?
От: Трурль  
Дата: 24.01.05 15:04
Оценка: +2 :))) :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Сергей Губанов, Вы писали:


СГ>>Результаты 1 — 10 из примерно 29 400 для JavaOS.

СГ>>Результаты 1 — 10 из примерно 82 300 для Oberon OS.
WH>Можно еще посмотреть для
WH>Результаты 1 — 10 из примерно 14 300 000 для java os
WH>Результаты 1 — 10 из примерно 285 000 000 для windows
WH>Результаты 1 — 10 из примерно 222 000 000 для linux

Результаты 1 — 10 из примерно 14 600 для porshe 911.
Результаты 1 — 10 из примерно 2 940 000 для volkswagen golf.
Re[30]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 24.01.05 16:42
Оценка: +1 -1 :)))
Здравствуйте, WolfHound, Вы писали:

WH>Ну в винде код шарится между процессами. В Обероне шарится не только код но и данные что не есть гуд. Ведь основная проблема программ не АВ как здесь пытаются представить защитники оберона(у меня и в С++ никаких АВ нет), а ошибки в логике которые к АВ не приводят но они случаются гораздо чаще и проблем с ними гораздо больше особенно если это просчет в арихитектуре программы у которой исходники измеряются мегабайтами и это не по тому что программисты тупые, а по тому что меньше всеравно не получится.


Наивный вопрос: что такое АВ?

WH>Я сейчас пишу под .НЕТ который защищен не хуже Оберона и прекрасно понимаю о чем говорю.


Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.

WH>1)Какие противники? Ты о чем? Чтобы у чегото были противники это что-то должно чегото стоить чего про обероны сказать нельзя. Народ тут просто развлекается...


Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет.
Если так, то хорошо: "консенсус" достигнут.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[36]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 25.01.05 14:13
Оценка: -4 :)
Здравствуйте, WolfHound, Вы писали:

WH> Вот там они и сидят. В принципе они только и нужны для написания библиотек низкого уровня. Короче можешь считать что они спрятаны в нутрь компилятора.


Если бы да кабы, то в носу бы выросли грибы.

WH> Кстати а как на счет ошибок в компиляторе оберона?...


ЧТО???????????????
Re[49]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 27.01.05 09:35
Оценка: -4 :)
Здравствуйте, Sinclair, Вы писали:

S>1. Что делать...

S>2. Что делать...
S>3. Что делать...
S>4. Как определять...

Еще одно подтверждение правоты AVC. Сначала люди говорят: "Этого не может быть!", а потом: "Черт побери, почему это работает?"

А ведь и в правду работает, а вот почему — это уже технические вопросы, за ответами обращайтесь к документации по конкретным системам.
Re[50]: Нужна ли Оберон-ОС защита памяти?
От: Курилка Россия http://kirya.narod.ru/
Дата: 27.01.05 09:44
Оценка: 1 (1) +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>А ведь и в правду работает, а вот почему — это уже технические вопросы, за ответами обращайтесь к документации по конкретным системам.


Т.е. по существу ответить не можем — сидите сами придумывайте ответы на ваши вопросы, так? Т.е. кроме слепой веры в то, что "работает", ничего нет?
Супер
Re[7]: Нужна ли Оберон-ОС защита памяти?
От: Sergey Россия  
Дата: 25.01.05 08:46
Оценка: +4
Hello, Сергей!
You wrote on Tue, 25 Jan 2005 08:31:34 GMT:

СГ> Здравствуйте, Cyberax, Вы писали:


??>>> Какая связь между языками Си/Си++ и драйверами?
??>>> Драйверы под оберон-системы пишутся на самих оберонах.

C>> А как суперзащищенный Оберон-драйвер будет работать с портами, IRQ и,

C>> не побоюсь этого слова, указателями?

СГ> Значит если в самом языке нет средств для работы на низком уровне, то

СГ> он не может на нем работать, так что ли? А вот, например, в языках
СГ> Си/Си++ нет встроенной возможности для параллельной работы, и что из
СГ> этого следует? А следует из этого то что используются внешние (по
СГ> отношению к самому языку программирования) библиотеки.

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

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[31]: Нужна ли Оберон-ОС защита памяти?
От: Pavel Dvorkin Россия  
Дата: 27.01.05 10:00
Оценка: +2 :))
Здравствуйте, DJ KARIES, Вы писали:

DK>Ибо нельзя испортить то, что не портится.


Все, что может испортиться, портится.
Все, что не может испортиться, портится тоже.

(C) Закон Мэрфи.

With best regards
Pavel Dvorkin
With best regards
Pavel Dvorkin
Re[19]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 16.02.05 09:35
Оценка: -3 :)
Здравствуйте, Кодт, Вы писали:

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

К>Как в языках со слабой типизацией абстрагируются от типа данных, так в Си (ещё не С++) — от размещения данных.
К>В обоих случаях — это паттерн "простота (хуже воровства)", для слабо типизированных языков — получается более простой транслятор, для Си — облегчённый рантайм.

В Обероне указатели есть (POINTER TO), но адресов и адресной арифметики нет. И именно из-за отсутствия адресов механизм абстракции не очень выразительный. Странно...




С другой стороны в оберонах есть элементарный тип "множество", которого нет в Си/Си++/Java/C#, а в языке Си даже нет булевского типа. А выразительность значит меньше. Опять странно...

Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

Как интересно в Си/Си++/Java/C# работают с битами? Наверное там битовые операции применяют прямо к числам? Вот несчастные программисты, как они там мучаются — ведь в Си/Си++/Java/C# множество битов и числа — это одно и тоже, хотя спроси любого математика так он ответит, что число — это одна математическая абстракция (теория чисел), а множество — совсем другая (теория множеств).



VAR s1, s2, s3: SET;
    n, m: INTEGER;
BEGIN
  s1 := {0,1,2,3}; (* Первые четыре бита = 1, остальные 32-4 = 28 битов равны 0 *)
  s2 := s1;
  n := 13;
  m := 2;
  INCL(s2, n); (* n-тый бит теперь равен 1 *)
  EXCL(s2, m); (* m-тый бит теперь равен 0 *)
  s3 := s1 + s2 + {25, 26}; (* Объединение трех множеств. В объединеном множестве присутсвуют все элементы присутсвующие во всех объединяемых множествах *)
  s3 := s1 * s2; (* Пересечение множеств - остаются только элементы присутсвующие и в первом и во втором множестве *)
  s3 := s1 - s2; (* Разность множеств. Из вычистаемого множества удаляются элементы присутсвующие в вычитаемом множестве *)
  s3 := s1 / s2; (* Симметричная разность множеств. Объединение разностей множеств s1 / s2 = (s1 - s2) + (s2 - s1) *)
  m := ORD(s3);  (* Sum i IN s3: 2^i *)
  s1 := BITS(n); (* {i | ODD(n DIV 2^i)} *)
Re[24]: Нужна ли Оберон-ОС защита памяти?
От: Кодт Россия  
Дата: 16.02.05 16:04
Оценка: +4
Здравствуйте, AVC, Вы писали:

К>>В С++, благодаря шаблонам, есть возможность контролировать размеры матриц на стадии компиляции


AVC>Гм. Как бы это поделикатнее сказать...

AVC>Мне даже интересно, а где этой возможности нет?
AVC>Например:
VAR a: ARRAY 10,10 OF REAL;
И так в большинстве языков...


Я имел в виду
VAR a: ARRAY 3,5 OF REAL;
    b: ARRAY 5,7 OF REAL;
    c: ARRAY 4,7 OF REAL;
    d: ARRAY 3,7 OF REAL;

d := a*b;
d := a*c; (* ошибка компиляции: несовместимые операнды *)
c := a*b; (* ошибка компиляции: несовместимые результат и приёмник *)


К>>Если рваный край, то просто массивов недостаточно, потребуется обвеска хотя бы в виде функций инициалазации. Как и в случае vector<vector<>>.

К>>А если прямоугольник — то действительно, раз — и готово!

AVC>Прямоугольник.




К>>Но опять же, в С++ можно сделать код, эквивалентный Обероновскому.

К>>Введём только, с помощью шаблона, тип "двумерный массив".
К>>Минимально, этого достаточно. Дальше — вагон и маленькая тележка функций, таких же, как в Обероне.

AVC>Конечно.

AVC>Си++, как всегда, выгодно отличается от Оберона своей простотой.

Планида у него такая. Бедность встроенных типов компенсируется мощностью пользовательских.
Перекуём баги на фичи!
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: Kh_Oleg  
Дата: 17.02.05 12:55
Оценка: +2 :))
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Kh_Oleg, Вы писали:


K_O>>
list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

ПК>>>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.
K_O>>
ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

K_O>>Читал, много думал...
K_O>>Почему взятие итераторов в скобки меняет смысл объявления?

К>Потому что есть правило "если нечто выглядит как объявление функции, это и есть объявление функции".

К>В данном случае,
К>
К>T name(U (u), V (v)); // где T, U, V - типы; name, u, v - идентификаторы
К>

К>U (u) можно трактовать как элемент объявления аргумента. Был бы там вместо u литерал или выражение — всё стало бы однозначно конструктором временного объекта типа U. А так — неоднозначность.
К>А вот (U(u)) уже невозможно трактовать как объявление аргумента.

Теперь понятно, спасибо.
Была бы возможность, я бы сейчас поставил языку С++ много минусов.
Re[22]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 17.02.05 15:01
Оценка: +3 :)
Сергей Губанов пишет:

> КЕ>Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит №

> четыре миллиарда?
> Нет, не будет. Хотя сам язык этого не запрещает. Все дело в реализации.
> Реализация BlackBox 1.5 дает следующее:
> MIN(SET) = 0
> MAX(SET) = 31
> (MIN, MAX — стандартные процедуры-функции)

Удивительно болшое множество....

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[23]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 18.02.05 10:46
Оценка: +1 -1 :))
Здравствуйте, Cyberax, Вы писали:

C>Сергей Губанов пишет:


>> КЕ>Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит №

>> четыре миллиарда?
>> Нет, не будет. Хотя сам язык этого не запрещает. Все дело в реализации.
>> Реализация BlackBox 1.5 дает следующее:
>> MIN(SET) = 0
>> MAX(SET) = 31
>> (MIN, MAX — стандартные процедуры-функции)

C>Удивительно болшое множество....


Ни что мешает сделать так:
TYPE
  BigSet = ARRAY 1000000 OF SET;
Re[32]: Нужна ли Оберон-ОС защита памяти?
От: Денис Федин Россия  
Дата: 27.01.05 11:07
Оценка: 5 (1) +1 -1
Здравствуйте, Шахтер, Вы писали:

AVC>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.


Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.


С++ конечно НЕ язык для детской песочницы, но наиболее крупные и сложные проекты как писались так и пишуться на C (не С++), одним из оснований является тот факт, что компилятор ANSI C найдется на любой платформе, хоть на специфической ОС для марсохода.
С++ в большей степени использовали и используют для т.н. 'сервисного' программирования, но этот кусок уже давно "отъедают" Java и .NET.
Re[23]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 16.02.05 21:52
Оценка: 2 (2) :)
Здравствуйте, Кодт, Вы писали:

AVC>>Прослеживается очень интересный подход.

К>и заметим, нездоровый...

Вот именно...
... это я и хотел сказать. Но проявил свойственные сторонникам Оберона такт и деликатность.

AVC>>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

AVC>>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.
К>Знаешь, почему? Потому что приверженцы Оберона всячески подчёркивают, что в самом языке достаточно фич, чтобы "было щастье". А избалованные библиотеками С++ники считают, что нет, не достаточно.

Если бы дело обстояло именно так, то "избалованные библиотеками С++ники" были бы правы.
(Что уже само по себе абсурдно... стоп! что это я? Спокойствие! держим себя в руках... такт и деликатность, такт и деликатность... )
Вообще-то приверженцев Оберона на RSDN раз-два и обчелся. Сергей Губанов, Трурль (изредка) и Ваш покорный слуга.
Так, мыслим... я тут хлебнул пивка, ща разберемся... Очевидно, имеются в виду мое "педалирование" отсутствия в Си++ гибких многомерных массивов и сегодняшний пассаж Сергея о множествах (на мой взгляд, не самый удачный).
Не... ну с гибкими-то массивами все ясно. В Си++ их как не было, так и нет. И, наверное, не будет, как недавно прозрачно намекнул Павел Кузнецов.
Правда, сторонники Си++ выражают такой бурный энтузиазм по поводу каждой отсутствующей в их языке фичи (я бы сказал — фундаментальной фичи )... Еще бы! повод написать новый класс!.. Может им Смоллток втихаря подсунуть?
Вообще-то интересное мнение об "Оберонщиках" здесь сформировалось! Мало того, что ребята выбрали минималистский язык (который иногда уподобляют RISC-процессору в мире CISC-ов), так они еще и ни в какую не соглашаются пользоваться библиотеками. Мол, "нет, уберите от меня ваши гадкие коды, я все сам!"
Дорогие мои (пьяная фамильярность ), неправда все это!
Вы в наших исходниках словечко IMPORT видели? Так это оно и есть — библиотеки!
А если нам вдруг мало становится чисто обероновских библиотек, то в нашем распоряжении еще библиотеки, написанные на других языках. Даю слово Метцелеру:

Now if you think of the reuse of legacy code, programs and libraries written for other languages, such as C/C++ and maybe Assembler, Pascal, Modula-2, Fortran or some other old language; or commercial libraries written for one of the popular programming languages: don’t worry, as long as whatever code you wish to use conforms to the platform standard for object modules and/or libraries (including dynamic link libraries, DLLs under Windows), you can use it with Oberon-2.

In fact, as long as the Oberon-2 compiler supports interfacing with external libraries (all of those outside of the ETH Oberon System do), it is usually enough to translate the standard .H header files, which are usually supplied with commercial libraries, into an acceptable format. The XDS compiler accepts Modula-2 style definition modules. These can be generated automatically from .H header files, for example by using the utility program H2D.EXE supplied at no cost by XDS (cf. corresponding documentation, or download it from their web site – www.excelsior-usa.com — if you don’t use their compiler).

Unfortunately, this possibility is largely ignored by many programmers. Even many computer magazines perpetuate the assumption that a program that wants to use an API written in C must also use C. According to this logic, all programs would still have to be written in machine language, as all programming languages must be translated into – or must interface with – machine language at some point, which is of course an absurd conclusion.

Скажу совсем криминальную вещь: мы бы и STL использовали. Если бы был объектник...

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[31]: Нужна ли Оберон-ОС защита памяти?
От: Sergey Россия  
Дата: 21.01.05 10:44
Оценка: 1 (1) +2
Hello, Сергей!
You wrote on Fri, 21 Jan 2005 10:35:21 GMT:

СГ> Как? Виндос мгновенно грохается, компьютер уходит в перезагрузку. Как

СГ> вообще что-либо создать если не то что моя программа больше не
СГ> работает, а сам комп ушел в перезапуск...

Винда сама крэшдамп создает, если это настроено. "System
properties->Advanced->Startup and recovery".

With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 24.01.05 15:09
Оценка: 1 (1) -2
Здравствуйте, Privalov, Вы писали:

AVC>>IMHO, "коллеги" пока что демонстрируют только свое непреклонное убеждение, что любая ОС должна быть клоном UNIX или Windows, везде и во все времена.

P>IMHO, OS/360 не похожа ни на Windows, ни на UNIX. Кстати, та же OS/2 тоже. И возможности защищенного режима она, AFAIR, использует лучше Windows. Не похожа она на клон. Речь шла о том, какой должна быть многозадачная ОС. О том, что нормальная ОС должна уметь защищать себя от криво написанных приложений.

Увы, я практически не знаком с устройством OS/360.
Теперь по существу дела.
В принципе, я согласен с Вами в том, что "центр тяжести" обсуждения сместился к многозадачным ОС. Еще точнее, достаточно ли в многозадачной ОС загрузить каждый используемый модуль однократно, или требуется дублировать код по соображениям безопасности.
На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".
Должен признать, что и наши аргументы иногда неубедительны.
Я думаю, все это по причине плохой информированности. Ведь по Windows, UNIX и Linux доступно море литературы, а вот книг по Оберону у нас в продаже нет.
Это совсем не означает, что Windows или Linux — хорошо, а Оберон — плохо. Это всего лишь политика издательств.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[55]: Один из способов решения
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 28.01.05 08:53
Оценка: 1 (1) -1 :)
Системный список указателей на пользовательские объекты можно написать так, чтобы он автоматически забывал о плохом объекте, псевдокод:
  Для каждого указателя из системного списка выполнить:
    извлечь указатель из списка и присвоить его значение вспомогательному временному указателю
    разыменовать вспомогательный указатель и что-нибудь поделать, например, попытаться нарисовать View если это она 
   (* в этом месте возникнет трап если объект не валиден *)
    вернуть значение вспомогательного указателя обратно в список указателей

Если случился трап, то плохой указатель назад в системный список возвращен не будет, далее система будет работать как ни в чем не бывало, а ГЦ приберет что надо.
Re[29]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 17.02.05 16:51
Оценка: 1 (1) :))
Здравствуйте, Павел Кузнецов, Вы писали:

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

ПК>Ессно. Я просто думал, что там уже есть какой-то готовый аналог.

Я сначала проверил.
Посмотрел ETH Oberon, XDS, BlackBox.
Прямого аналога нет, вообще все строится по другому. (Это, в общем-то и интересно.)
Затем сделал пару набросков на Обероне.
Обобщенный код получить можно, но надо продумывать иерархию классов, а я что-то не в духе сегодня.
В общем, мне не понравилось.
А в конце, естественно: да что я вам — Пушкин, что ли?!

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[27]: Нужна ли Оберон-ОС защита памяти?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 20.01.05 13:36
Оценка: +1 -2
Здравствуйте, Privalov, Вы писали:

P> Выходит, что все приложения выполняются в едином адресном пространстве? Так мы это уже проходили. Windows 3.1 — первое, что приходит в голову.


Повторяю, в оберон-системах, в отличие от Windows 3.1, приложения вообще не знают что такое сырая память. Указатели в них есть, но указывают они не на сырую память, а только на объекты или на массивы, соответственно, никакой адресной арифметики с указателями делать нельзя, а значит нельзя испортить память.
Re[28]: Нужна ли Оберон-ОС защита памяти?
От: Cyberax Марс  
Дата: 20.01.05 14:58
Оценка: +3
Сергей Губанов пишет:

> P> Выходит, что все приложения выполняются в едином адресном

> пространстве? Так мы это уже проходили. Windows 3.1 — первое, что
> приходит в голову.
> Повторяю, в оберон-системах, в отличие от Windows 3.1, приложения
> вообще не знают что такое сырая память. Указатели в них есть, но
> указывают они не на сырую память, а только на объекты или на массивы,
> соответственно, никакой адресной арифметики с указателями делать
> нельзя, а значит нельзя испортить память.

Hint: найдите все свои письма со словами "внешнаяя библиотека"...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[6]: Нужна ли Оберон-ОС защита памяти?
От: AVC Россия  
Дата: 24.01.05 14:35
Оценка: :)))
Здравствуйте, Sergey, Вы писали:

S>Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF. Требуется

S>установить байт 0xE4000040 в 0xCE, шоб точку на экране показать. Как это
S>сделать, принимая во внимание, что "вопрос "...менять содержимое памяти,
S>принадлежащей другому приложению" не имеет физического смысла, поскольку в
S>языке нет способа узнать что-либо про память, нельзя получить численное
S>значение указателя (указатель — вещь в себе, его численное значение, если бы
S>его можно было бы получить, оказалось бы вовсе не константой, а то и дело
S>изменялось бы благодаря стараниям сборщика мусора)."?

Такой проблемы в Обероне нет, как и в Модуле не было.
Неужели единственный способ обратиться к видеобуферу — это
(* ((unsigned char *) 0xE4000000)) = 0xCE;

Чем хуже, скажем,
VideoBuffer.SetPoint(0, 0, 0xCE));

или
P[0][0] := 0xCE;

где P — указатель на видеобуфер?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[5]: Нужна ли Оберон-ОС защита памяти?
От: Дарней Россия  
Дата: 25.01.05 04:44
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Драйверы под оберон-системы пишутся на самих оберонах.


Это мы уже проходили.
Которые делаются с помощью специальных "низкоуровневых библиотек", которые позволяют с легкостью прибить всю систему, и таким образом сводят на нет все преимущества как ОС, так и языка.
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[53]: Эксперимент
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 27.01.05 15:19
Оценка: -3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Sinclair, Вы писали:


S>> К примеру, это DeskTop. Я передаю ему ссылку на свое окно, поскольку именно десктоп берет на себя управление окнами. Вот меня надо убить. Ясно, что мое окно входит в компоненту связности — у меня есть ссылка на него, да и окно ссылается на своего автора. Угу. А DeskTop ссылается на окно. Какую из ссылок ты будешь обнулять?


СГ>А что если я отвечу на этот вопрос? Вы свою шляпу обещаете съесть?


Давайте-ка, например, поиздеваемся над старым добрым BlackBox.... (Ваш модуль DeskTop = Views из BlackBox)

Мой модуль содержит опредение типа MyView расширения типа Views.View. Я создаю объект MyView с помощью процедуры NewMyView() затем регистрирую его в системе и прошу показать с помощью Views.OpenView(). Вот код:
PROCEDURE OpenNewView*();
BEGIN 
  Views.OpenView( NewMyView() )
END OpenNewView;

Стало быть модуль Views запомнил мой объект. Появляется новое окно в котором отображается моя видимость (MyView).


В модуле Kernel, который самый что ни на есть системный, и простым смертным запрещается его использовать, есть вот такая процедура-убийца-модулей:
PROCEDURE UnloadMod (mod: Module);

Поступим с ней вот так:
VAR mod: Kernel.Module;
BEGIN
  mod := Kernel.ThisLoadedMod("имя моего модуля");
  Kernel.UnloadMod(mod);

Ну и что же, насильно выгружаю мой модуль с определением типа MyView в то время как моя видимость с ним активно работает (то бишь отображается). Выскакивают два окошка с трапами — игнорирую их (close). Вот и все.
  • BlackBox не упал.
  • Графическая оконная подсистема не упала.
  • В остальных окнах все отображается как и раньше, можно писать тексты; открывать/закрывать и т.д...
  • В том окне, в котором раньше отображалась моя видимость (MyView) сейчас нарисована аккуратная сеточка — дескать отображать более нечего — видимость скоропостижно сдохла.



    Ну, что, съели? Еще возникать будете? Может еще какой-нибудь эксперимент поставим?
  • Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 27.01.05 15:35
    Оценка: +1 -1 :)
    Здравствуйте, AVC, Вы писали:


    AVC>(С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не дезинформировать общественность.

    AVC>Действительно, некоторые страны (мне известно о Канаде и UK) ограничивают применение Си/Си++ в критических областях, прежде всего в области ПО для атомной энергетики.

    Неужели, они ситсемы реального времени пишут на Обероне?


    Представляю себе сообщение информационного агентва:

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


    Короче, ГЦ и СРВ — это вещи несовместимые.
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 16:04
    Оценка: :)))
    Здравствуйте, Курилка, Вы писали:

    К> Ага, а как же пример с десктопом — он знает об окне, но десктоп не удаляется...


    Значит сделано по умному.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 20.02.05 00:05
    Оценка: 48 (2)
    Здравствуйте, Cyberax, Вы писали:

    C>Я не спорю, коллекции можно реализовать вполне нормально (java.util.* —

    C>этому пример), но при этом потеряем статическую типизацию. И что самое
    C>важное, все дополнительные возможности языка Oberon так же пойдут лесом.

    Внесу ясность.
    Я за статическую типизацию.
    У меня привычки Си++ного программиста, и мне статической типизации в Обероне не хватает. (Я признавал это с самого начала.)
    Поэтому я и думаю, как бы добавить эту фичу в Оберон минимальной ценой.
    Но давайте посмотрим на это с другой стороны. Хотя бы на минуту.
    На этих (возможно, многих раздражающих) топиках об Обероне обсуждались две темы: язык Оберон и ОС Оберон.
    Так вот у каждого из них нашлось ровно по одному существенному недостатку.
    В ОС Оберон сомнительна та особенность, что каждый модуль представлен в оперативной память единственной копией.
    Проблема связана со статическими переменными при вытесняющей многозадачности.
    Если мы должны были убить процесс, то что делать с переменными модуля (локальные переменные процесса живут в стеке и регистрах, с ними проблем нет) после убийства процесса? А если они были "испорчены" плохим процессом?
    В качестве (временного) решения я предложил грузить сегмент данных прикладных модулей заново для каждого нового процесса. (Модули ядра ОС по прежнему грузятся в память однократно.)
    В таком случае проблема статических переменных решается автоматически (они убиваются системой вместе с "провинившимся" процессом), но у нас остается единое адресное пространство.
    Что касается языка Оберон, его единственным недостатком является отсутствие средств обобщенного программирования.
    Что, в принципе, легко исправляется. В предыдущем посте я попытался предложить "минималистский" вариант решения этой задачи. (Могут быть и другие варианты.)
    Замечу, что практически все интересные новшества в ЯП возникают именно в паскалеподобных языках.
    ИМХО, исправить язык, у которого есть один (хотя и существенный) недостаток, гораздо проще, чем пытаться исправить язык, у которого недостатков много. (Пусть даже они иногда мелкие, но, к сожалению, заложены в самом основании языка. Как, например, адресная арифметика и неопределенность природы указателей в Си++.)
    Кстати, все те достоинства, которыми похваляется язык Си++, давно не новость в мире языков программирования.
    Вот у меня на полке стоит старая уже книжка П.Вегнера "Язык програмирования АДА". Издана в 1980, переведена у нас в 1983.
    Здесь и значения по умолчанию, и перегрузка операторов, и шаблоны. Хоть STL пиши!
    Вот пример перегрузки операторов:
    function "+" (x,y: COMPLEX) return COMPLEX is
    begin
      return (x.RE+y.RE, x.IM+y.IM);
    end;
    А вот пример обобщенной процедуры
    generic (type T)
    procedure SWAP (x,y: in out T) is
      temp: T;
    begin
      temp := x;
      x := y;
      y := temp;
    end SWAP;
    и ее конкретизации
    procedure SWAP_INT is new SWAP(INTEGER);
    procedure SWAP_VECT is new SWAP(VECTOR);
    Есть и родовые пакеты (модули).Например:
    generic (type T; SIZE: INTEGER := 100)
    package SYMTAB is ...
    и т.д.
    В Си++ интересен не столько сам язык, а появившиеся за последнее время новые идиомы (те же умные указатели и т.п.)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 21.02.05 06:10
    Оценка: 30 (2)
    Здравствуйте, AVC, Вы писали:


    AVC>В качестве примера рассмотрим список.
    MODULE Lists;
    AVC>TYPE
    AVC>  List = POINTER TO ListNode;
    AVC>  ListNode(T) = RECORD
    AVC>    data: T;
    AVC>    next, prev: List;
    AVC>  END;
    А где-то в прикладном модуле можно было бы написать так:
    TYPE
    AVC>  Foo = POINTER TO FooDesc;
    AVC>  FooDesc = RECORD ... END;
    AVC>VAR
    AVC>  FooList: Lists.List(Foo);
    Я, конечно, привожу только набросок, в нем могут быть какие-то несогласованности.


    А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?

    TYPE 
      Ptr(A) = POINTER TO A;
      List(A) = Ptr(ListDesc(A));
      ListDesc(A) = RECORD elem: Ptr(A); next: List(A) END;
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 20.01.05 12:12
    Оценка: 23 (2)
    Здравствуйте, Privalov, Вы писали:

    P>Здравствуйте, AVC, Вы писали:


    AVC>>Имеет значение. Да еще какое!

    AVC>>Просто Вы лично не пишете операционных систем.
    AVC>>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность?
    P>Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?

    Правильно ли я понимаю, что Вы отождествляете приложение и процесс? (По крайней мере, такая логика прослеживается: одно приложение => одна задача.)
    В Оберон-системе нет понятия приложение (=программа).
    Есть понятия: модуль и команда. Команда — это экспортируемая модулем процедура без параметров. Если Вам приведется воспользоваться Оберон-системой, то вызвать команду легко: щелкаете мышью на строке вроде модуль.процедура.
    Один модуль может использоваться сразу многими задачами.
    Многозадачность в Обероне может быть как кооперативной так и вытесняющей.
    Исторически первая Оберон-система обеспечивала кооперативную многозадачность (single-process multitasking). Отсюда происходит ряд недоразумений в головах критиков Оберона.
    Некоторые полагают, что Оберон в принципе не может использовать вытесняющую многозадачность. Это заблуждение.
    Вторые полагают, что кооперативная многозадачность должна приводить к обязательному подвисанию системы, если какой-нибудь горе-программист написал бесконечный цикл вроде LOOP END. Это тоже заблуждение.
    Третьих беспокоит безопасность ядра Оберона. Это беспокойство мне вообще непонятно, т.к. объекты ядра спрятаны от модулей расширения, а если требуется предоставить к ним доступ (хэндлы), то они экспортирутся в скрытом режиме.
    Четвертые (и их, кажется, большинство) не могут себе представить создание нового процесса без UNIX-овского примитива fork(). (При этом они спокойно пишут многопоточные приложения и вопросов у них не возникает.) В Модуле-2 и Обероне-2 каждый процесс безраздельно владеет своими локальными (стековыми) переменными, а для разделяемых переменных существуют мониторы и семафоры.
    Пятые убеждены, что для использования механизма исключений необходымы расширения языка, вроде ключевых слов try, catch и throw. Это тоже заблуждение. В ETH Обероне используется другой механизм. С ним можно ознакомиться здесь:
    http://www.ssw.uni-linz.ac.at/Research/Papers/Hof97b.html

    AVC>>Когда это OS/360 на 80286 работала?

    P>Возможно, я где-то некорректно выразился. Может быть, правильнее будет так.

    Это напоминает мне фильм "Человек за бортом": "Ну, может быть, где-то самую малость ты права..."

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.01.05 11:37
    Оценка: 21 (2)
    Здравствуйте, Sergey, Вы писали:

    S>Каким образом можно не дать приложению выжрать всю память в винде, если не

    S>секрет?
    В винде секретов нет. RTFMSDN "SetInformationJobObject"

    Остальные вопросы по управлению ресурсами я поскипаю.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 11.02.05 09:29
    Оценка: 18 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>Здравствуйте, RailRoadMan, Вы писали:


    RRM>>1) Идем на сайт BlueBottle, далее Download Current, далее AosSysSrc.zip, далее AosKernel.mod, смотрим


    СГ>Спасибо за такой ответ.

    СГ>Кроме Вас еще никто не сподобился скачать BlueBottle и посмотреть на ее исходный код.

    Ну я особо не вникал в код , интересно было посмотреть как там низкоуровневый аспекты реализованы, оказалось на асме (ну по другому никак). Только имхо, встроенный ассемблер — не очень удачное решение, проще отдельный ассемблер, переносить код на другие архитектуры лучше будет.

    СГ>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.


    Вот этот вопрос принципиальный, если там все так просто с вирусами, то эту систему нельзя использовать там, где неквалифицированный (в хорошем смысле слова) пользователь запускает программы полученные на стороне. На атомной станции (вы писали, что там вроде оберон применяется) там понятно дело левых программ нет, их долго тестируют, проверяют и т.п. можно и на обероне писать. Кстати ПО для автомобильной электроники на С пишется, а в качетсве ОС там OSEK (www.osek-vdx.org), не атомная сканция конечно, но тоже критично.
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Шахтер Интернет  
    Дата: 28.01.05 01:07
    Оценка: 12 (1) +1
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Шахтер, Вы писали:


    AVC>>>Работает же.

    AVC>>>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.
    AVC>>>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.

    Ш>>Ну может быть, всё же не надо дезинформировать общественность. На Марс летал vxWorks, написанный на C.


    AVC>(С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не дезинформировать общественность.


    AVC>Действительно, некоторые страны (мне известно о Канаде и UK) ограничивают применение Си/Си++ в критических областях, прежде всего в области ПО для атомной энергетики.


    Вот это утверждение гораздо больше похоже на правду.

    AVC>>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.

    Ш>>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.

    AVC>И какие из них САМЫЕ КРУПНЫЕ?


    Боюсь, что у меня нет под рукой списка, из которого можно выбрать наиболее крупные.
    Но можно сходить на страничку Страуструпа за примерами.
    ... << RSDN@Home 1.1.0 stable >>
    В XXI век с CCore.
    Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 10:36
    Оценка: 10 (1) +1
    Здравствуйте, Дарней, Вы писали:

    AVC>>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.

    AVC>>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
    AVC>>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

    Д>А где сейчас те языки, операционки и вертолеты?


    По-моему об этом уже достаточно много говорили.
    Видимо, подтекст такой, что сейчас это не используется?
    Это не так.
    Паскаль используется.
    Модула-2 используется в космической промышленности (кстати, в том числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
    Оберон-2 используется, например, в NASA.
    Беспилотные вертолеты по-прежнему летают. (Кстати, OLGA означает Oberon language goes airborne.) Хотя эта сфера развивается очень быстро, и я допускаю, что ПО, написанное лично Виртом, в новых образцах уже не используется.
    Кстати, ETH занимает одно из лидирующих мест в соответствующих исследованиях, уступая, возможно, лишь MIT.
    Если Вам интересна история этого проекта, вот выдержка из диссертации о применении методов спутниковой навигации в беспилотных вертолетах.

    The helicopter project was initiated in the late 1980’s by Prof. H.P. Geering,
    head of the Measurement and Control Laboratory at the Swiss Federal
    Institute of Technology (ETH) Zurich. Since the establishment of the
    project, both theoretical as well as practical aspects have been covered. In
    consequence, a remarkable laboratory environment for indoor testing of an
    electrical helicopter has been developed.
    Subsequent to successful flight experiments with the indoor electrical helicopter
    (Weilenmann, 1994), the author was offered to continue and complement
    the helicopter project with an unmanned, free-flying helicopter based
    on INS/GPS navigation and modern control theory. During 1995 until 2000,
    the Swiss Heli Team ETH, which was initiated by the writer, succeeded to
    develop two helicopter prototypes, whereby the latter has demonstrated
    completely autonomous flights, including lift-off and landing.
    In 1996 the Swiss Heli Team ETH participated in the International Aerial
    Robotics Competition which was organized by the Association for Unmanned
    Vehicle Systems International (AUVSI). The Swiss team achieved
    the second place behind the team from MIT. Subsequent to the successful
    participation at the competition, Prof. W. Schaufelberger and Prof. N.
    Wirth
    significantly supported the helicopter project for further developments.

    Что касается идей.
    Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.
    Вы можете найти их и в языках Java и C#, и в JVM и в .NET.
    Что касается учебной сферы, то по книгам, языкам и системам Вирта учатся во всем мире. (В частности, ETH Oberon System 3 изучается в ряде западных учебных программ. Я уж не говорю о том, как изучали ее код в Sun в начале 90-х годов. Очень творчески. )
    Хочу отметить (как личное), что именно в книгах Вирта я впервые встретил примеры построения целых программ от начала до конца, а не общие рассуждения в стиле Буча.
    Так что небезполезную жизнь прожил Вирт, как бы Вам, видимо, не хотелось доказать обратное.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re: Нужна ли Оберон-ОС защита памяти?
    От: Borisman2 Киргизия  
    Дата: 01.02.05 09:08
    Оценка: 7 (2)
    Письмо в РСДН касательно программной реализации защиты в ОС Оберон

    Уважаемые коллеги! Прежде всего хотел бы предупредить, что я не являюсь ни сторонником, ни противником ОС Оберон и связанных с ней технологий. Также я не являюсь экспертом по ОС Оберон или ОС BlueBottle, поэтому не могу высказываться о том, какая конкретно реализация того или иного механизма применяется в этих ОС.

    1. Несколько общефилосовских слов по поводу программно/аппаратной защиты.

    Как я уже неоднократно подчеркивал, между програмной и аппаратной защитой нет принципиальной разницей, как нет принципиальной разницы между программной и аппаратной реализацией ЛЮБОГО алгоритма. Теоретически, реализовать машину Тьюринга можно как аппаратно, так и программно.

    Есть, однако, разница в УРОВНЕ, на котором будет работать такая защита. Не секрет, что в индустрии IT повсеместно используется многоуровневая (многослойная) организация вычислений, когда один уровень (например, уровень программы на ассемблере) использует другой уровень (уровень железа). Таким образом, неформально можно сказать, что прослеживаются следующие уровни:
    1) Чисто аппаратный уровень (триггеры, регистры и прочая схемотехника)
    2) Микропрограммный уровень (микрокод)
    3) Уровень ассемблера
    4) Уровень managed-кода

    Строго говоря, на архитектуре х86 мы не можем разделить 1 и 2 уровни, так как у нас нет доступа к микрокоду процессора. Но это не принципиально.

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

    Таким образом, в традиционной схеме так называемой аппаратной защиты мы располагаем логику защиты на уровне 1-2
    В случае с ОС Оберон логика должна располагаться на уровне 3, так как программы, написанные на Оберон и использующие сборщик мусора можно в какой-то мере считать managed кодом уровня 4. Принципиально, такая защита ничем не хуже, чем защита на уровне 1-2, до тех пор, пока мы не начинаем обходить ее (т.е. не начинаем программировать на ассемблере)


    2. Вопросы о процессах и сборщике мусора

    Неоднократно высказывался вопрос следующего содержания: Что будет, если процесс (активный объект) начнет вести себя неадекватно и его понадобится убить ? Справится ли с этим сборщик мусора ?
    Мне кажется, что во второй части вопроса допущена явная неточность и вот почему.
    В данный конкретный момент времени существуют две иерархии объектов:
    1) Иерархия ссылок (объект А держит ссылку на объект Б)
    2) Иерархия исполнения (метод Foo объекта А вызвал метод Bar объекта Б и теперь метод Bar исполняется)

    Вопрос об "убийстве активного процесса" не имееет отношения к иерархии ссылок, а имеет отношение к иерархии исполнения. Забавно то, что применение нестандартной терминологии (активный объект) наталкивает нас на неверные интерпретации.

    Что такое активный объект ? Это объект, метод которого выполняется в многозадачной или одно задачной среде. Что такое "убить активный объект"? Это по сути не означает "удалить объект", это означает "приостановить выполнение метода объекта, т.е. сделать его пассивным". Сборщик мусора тут вообще ни при чем. Если кто-то сохранил ссылку на объект, ничего страшного в этом нет.



    3. Субъективное мнение о безопасности процессов в едином адресном пространстве

    На необходимость наличия различных адресных пространств в большой степени влияют применяемые в данной конкретной системе инструменты программирования. Может оказаться, в частности, что разделение пространств вовсе и не требуется (пример — многопоточность Mozart Oz) или наоборот, жизненно необходимо. В любом случае, приходится опираться на некоторые априорные знания о тех программах, что будут исполняться в системе. Безопасность процессов в едином адресном пространстве (если это требуется) может быть достигнута чисто программными средствами и типичное тому подтверждение — Erlang.

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

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

    4. Выводы

    Суммируя вышесказанное, считаю, что реализация надежной защиты многих процессов чисто программными методами возможна и перспективна, однако в настоящее время обречена на специальное применение.
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 20.01.05 13:29
    Оценка: 6 (2)
    Здравствуйте, Sergey, Вы писали:

    S>Кстати, на практике и в системах с разделяемыми адресными пространствами

    S>приложений нет никаких гарантий, что одно приложение не уронит всю систему.
    S>Вот, например, не далее чем месяц назад у меня запуск Java Web Start
    S>стабильно валил WinXP в синий экран

    У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 10.02.05 17:44
    Оценка: 6 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    1) Идем на сайт BlueBottle, далее Download Current, далее AosSysSrc.zip, далее AosKernel.mod, смотрим

    PROCEDURE -AtomicAdd*(VAR x: LONGINT; y: LONGINT);
    CODE {SYSTEM.i386}
    POP EBX
    POP EAX
    LOCK
    ADD DWORD [EAX], EBX
    END AtomicAdd;

    А вот из AosMemory.mod кусочек.

    PROCEDURE LoadGDT(base, size: LONGINT);
    CODE {SYSTEM.i386, SYSTEM.Privileged}
    SHL size[EBP], 16
    MOV EBX, 2
    LGDT size[EBP][EBX]
    END LoadGDT;

    Возникает вопрос, по зачем тут втроенный ассемблер, если все что нужно можно написать на Oberon? Или это ран тайм языка? Очень похоже. Т.е. в основе все как и везде, машинный код и ассемблер, и без него никуда

    2) Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код
    MOV BX,<левый адрес>
    MOV [BX],<всякий мусор>
    Проехались по чужой памяти, более того эта пара интсрукций не является привеллегированной и в общем случае нельзя сказать, она допустима или нет (т.е. на проверки кода перед исполнением особо рассчитывать не приходится). Просматривается широкий простор для создателей вирусов.

    3) По поводу операционных систем. ОС — некое ПО предоставляющее сервисы, пользователю или другому ПО не важно, тогда чем простите вам ран-тайм языка отличается от простой ОС. Да ничем.

    4) Вот теперь представьте, что ВЫ хотете написать программу, которая работает на голом железе (без всяких там ран-таймов), ничего не выйдет. Окажется что сначала рантайм спортировать надо — вот она ваша ОС, размер немного другой, суть та же. А на С (C++ немного сложнее) как делать нефиг, ПО для контроллеров так и пишут. Железку проинициализировал, стек настроил, вызвал код на С, далее ОС инициализим (если она вообще нужна), и поехали, тут вам и многопоточность, тут вам и мьютексы и состояние ожидания, и активные объекты если надо

    5) А вы вообще про ОС реального времени слышали? Возмите код хоть одной из них, посмотрите.


    P.S. Специально зарегистрировался чтобы ответить

    СГ>Здравствуйте, Cyberax, Вы писали:


    C>>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных

    C>>ОС. Еще рекомендую почитать про O(1) планировщики.

    СГ>spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).
    Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 19.01.05 12:38
    Оценка: 3 (1) :)
    Здравствуйте, Privalov, Вы писали:

    C>>А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО

    C>>проектировать железо.
    P>И, кстати, под еще целую массу языков тоже не нужно.

    Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"?

    21.01.05 11:53: Ветка выделена из темы Системность
    Автор: Сергей Губанов
    Дата: 12.01.05
    — AndrewVK

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[19]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 15.02.05 11:37
    Оценка: 3 (1) :)
    Здравствуйте, Кодт, Вы писали:

    К>Здравствуйте, AVC, Вы писали:


    AVC>>Правда, в Обероне таких проблем вообще нет. (Он просто грамотно сделан.)

    AVC>>Но ведь это такой скучный язык.
    AVC>>А вот Си++ — это романтика.
    К>На самом деле, указатели в Си — с одной стороны, крайне небезопасный, а с другой — очень выразительный механизм, в том числе — механизм абстракции.
    К>Как в языках со слабой типизацией абстрагируются от типа данных, так в Си (ещё не С++) — от размещения данных.
    К>В обоих случаях — это паттерн "простота (хуже воровства)", для слабо типизированных языков — получается более простой транслятор, для Си — облегчённый рантайм.

    Мысль понятна.
    Но согласиться с ней трудно.
    Действительно, рантайм в Си "облегченный" (и "облегчается" он, похоже, в самых неожиданных местах оперативной памяти. ).
    Но вот только компиляторы Си "весят" больше, чем компиляторы Оберона, и код в них — запутаннее. (Си++ я, по понятным причинам, вообще не упоминаю.)

    К>Красивое развитие идеи указателей — это итераторы STL. Хотя с таким же, а то и с большим успехом можно было вместо итераторов ввести понятие "диапазон", и такие попытки делаются.


    Согласен.
    Вероятно, именно STL дала новую жизнь Си++.
    На удивление, именно адресная арифметика и перегрузка операторов хорошо вписываются в STL.
    (Здесь сишный синтаксис отпразновал незапланированный успех.)
    Но, с другой стороны, это означает, что все соответствующие дефекты Си/Си++ проникли (как этакие синтаксические вирусы ) в STL, boost и т.д.

    К>Оберон — да, действительно скучный язык. Типизацией по пальцам надавал, размещением по пальцам надавал, а средств абстракции — не надавал


    Сорока-ворона кашу варила...
    Почему же это вдруг не надавал?
    Модули и расширение типов позволяют реализовать любую абстракцию.
    Причем инкапсуляция не в пример лучше, чем в Си++.
    (Дискуссию о плюсах и минусах перегрузки операторов пока разворачивать не будем. Я знаю диалекты Оберона, где такая перегрузка есть. Но вот хорошо ли это?)
    Вообще, для меня в языках программирования очень важна возможность введения абстрактных типов данных.
    Даже мое первый пост на RSDN был именно об АТД (и их связи с математическими моделями; я же все-таки прикладной математик).
    Многие программисты почему-то думают, что настоящая абстракция возможна только на Си++.
    Побывал недавно в своей старой конторе. (Там где все сидели в отладчике Watcom C++. ) Сказал, что увлекся Обероном. До драки дело не дошло (я всерьез опасался ). Но народ удивлялся и ссылался как раз на мою страсть к АТД и математизированному подходу. А я отвечал: в Обероне все есть (как в Греции ).

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 20.01.05 08:25
    Оценка: 1 (1) +1
    Сергей Губанов пишет:

    > P>Что, в Оберон-системах приложение может свободно менять содержимое

    > памяти, принадлежащей другому приложению? Или это однозадачная система?
    > В Оберонах нет такого понятия как память (то бишь адресного
    > пространства как такового), хотя указатели есть.

    Есть в Обероне понятие "память", как и в других языках. То что оно
    /скрыто/ (слабенько так) вовсе не означает, что его нет.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 20.01.05 12:20
    Оценка: 1 (1) +1
    Hello, Павел!
    You wrote on Thu, 20 Jan 2005 12:06:00 GMT:

    ??>> В Оберонах нет такого понятия как память (то бишь адресного
    ??>> пространства как такового), хотя указатели есть. Все что можно сделать
    ??>> с указателем p так это <...> Таким образом, вопрос "...менять
    ??>> содержимое памяти, принадлежащей другому приложению" не имеет
    ??>> физического смысла <...> А раз так, то необходимость в создании
    ??>> множества виртуальных адресных пространств (для безопасности) больше
    ??>> не существует <...>

    ПК> Это в теории. А на практике, как мы выяснили ранее, операции, требующие

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

    Кстати, на практике и в системах с разделяемыми адресными пространствами
    приложений нет никаких гарантий, что одно приложение не уронит всю систему.
    Вот, например, не далее чем месяц назад у меня запуск Java Web Start
    стабильно валил WinXP в синий экран

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: alexeiz  
    Дата: 21.01.05 10:00
    Оценка: 1 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2.


    Даже с закрытыми глазами можно сказать, что это драйвер.

    >Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.


    Нечего мудрить. Когда система падает, нужно memory dump создавать, потом с ним в отладчик и !analyze. Честное слово, это базовые знания.
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 21.01.05 10:59
    Оценка: 1 (1) :)
    Сергей Губанов пишет:

    > A>Даже с закрытыми глазами можно сказать, что это драйвер.

    > Спасибо.
    >
    > A>Нечего мудрить. Когда система падает, нужно memory dump создавать,
    > потом с ним в отладчик и !analyze.
    > Как? Виндос мгновенно грохается, компьютер уходит в перезагрузку. Как
    > вообще что-либо создать если не то что моя программа больше не
    > работает, а сам комп ушел в перезапуск...

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 24.01.05 17:23
    Оценка: 1 (1) +1
    Здравствуйте, AVC, Вы писали:

    AVC>Наивный вопрос: что такое АВ?

    Транслитерация (лень раскладку переключять) сокращения AV от Access Violation

    AVC>Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.

    А фанаты смаллтолка утверждают что эти системы происходят от смаллтолка...

    AVC>Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет.

    А с логикой тут все в порядке. Лично мне Оберон глубоко по барабану(Я сюда просто потрепатся захожу когда работа задалбывает). А тебе и Губанову судя по всему нет. Вот вы и кидаетесь на всех кто высказывает сомнения в том что оберон решит все проблемы человечества.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[6]: Как пишут драйверы на safe языках программирования.
    От: Sergey Россия  
    Дата: 25.01.05 08:35
    Оценка: 1 (1) +1
    Hello, Сергей!
    You wrote on Tue, 25 Jan 2005 08:24:30 GMT:


    СГ> Драйверы под оберон-системы пишутся на самих оберонах.


    СГ> Для этого используют модуль SYSTEM


    СГ> http://www.oberon.ethz.ch/SYSTEM.html


    А есть средства, запрещающие использовать этот модуль простым смертным?
    Потому что с его помощью систему в капусту нашинковать ничуть не сложнее,
    чем с помощью С или ассемблера.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Ни шашки, ни шинели, ни лошади...
    От: SilverCloud Россия http://rodonist.wordpress.com
    Дата: 26.01.05 19:35
    Оценка: 1 (1) +1
    Здравствуйте, DJ KARIES, Вы писали:

    DK>В настоящей Оберон-системе не было бы ни GDI+, ни DirectDraw7, ни Windows XP SP2.

    Ибо не было бы ни нормальной графики, ни интерфейса к драйверам, ни безопасности
    Who needs information?
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 16:31
    Оценка: 1 (1) +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Можно, но надо-ли?


    Я уже говорил, что операции над голыми типами — это возможность накосячить.
    Пример с данным кодом:
    TYPE LongSet = ARRAY OF SET;
    PROCEDURE SetAdd(VAR dst: LongSet; x: INTEGER);
    PROCEDURE SetUnion(a,b: LongSet; VAR dst: LongSet);
    PROCEDURE SetCross(a,b: LongSet; VAR dst: LongSet);
    PROCEDURE IsEmptySet(a: LongSet): BOOLEAN; (* проверяет, что вектор заполнен пустыми множествами *)
    PROCEDURE CompactSet(VAR dst: LongSet); (* отбрасывает хвост массива, заполненный пустыми множествами *)
    .....
    
    TYPE StackOfSets = ARRAY OF SET; (* другой логический смысл такого же контейнера *)
    PROCEDURE PushSetIntoStack(VAR stack: StackOfSets; item: SET);
    PROCEDURE PopSetFromStack(VAR stack: StackOfSets; VAR item: SET);
    PROCEDURE IsEmptyStack(stack: StackOfSets): BOOLEAN; (* проверяет, что размер равен нулю *)
    .....
    
    VAR x: LongSet;
        y: StackOfSets;
    BEGIN
      ...
      PushSetIntoStack(x, {0,1,2} ); (* Перепутали x и y. Компилятор сожрал. *)
      ...
    END;


    В некоторых, критичных, местах бывает полезно даже числовые типы заворачивать в классы, чтоб с размерностями проблем не было.
    (В С++ это проще, там есть перегрузка операторов; но это так, к слову).
    Перекуём баги на фичи!
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 19.01.05 13:19
    Оценка: +1 :)
    AVC пишет:

    > C>>А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО

    > C>>проектировать железо.
    > P>И, кстати, под еще целую массу языков тоже не нужно.
    > Не подскажете, случайно, для каких языков потребовался *защищенный
    > режим*, чтобы написанные на них программы друг друга не "убивали"?

    Для ВСЕХ.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[23]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 19.01.05 15:05
    Оценка: -2
    Здравствуйте, Privalov, Вы писали:

    P>Защита приложений — одна из функций многозадачной операционной системы. При этом не имеет никакого значения, на каком языке программирования реализовано то или иное приложение.


    Имеет значение. Да еще какое!
    Просто Вы лично не пишете операционных систем.
    В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность?

    P>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.


    Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали.
    Когда это OS/360 на 80286 работала?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 20.01.05 07:52
    Оценка: -1 :)
    Здравствуйте, Privalov, Вы писали:

    P>Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?


    В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть.

    Все что можно сделать с указателем p так это присвоить ему значение другого указателя (соответствующего типа) p := q или NIL, p := NIL, сравнить его значение со значением другого указателя (аналогичного типа) p = q, p # q, или с NIL p = NIL, p # NIL, и, наконец, создать новый объект NEW(p) в том случае если тип объекта, на который он указывает позволяет это сделать, а также разыменовать его p^ получив доступ к объекту на который он указывает (причем сам символ "^", когда он очевиден, писать не обязательно).


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

    А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует — достаточно одного единого на всю систему адресного пространства, а безопасность гарантируется языком программирования, рантайм проверками индексов массивов, контролем приведения типов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 20.01.05 13:42
    Оценка: +2
    Сергей,

    > У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.


    То, что в процессе работы программы никаких исключений не возникает, еще не означает, что она работает корректно. Вообще, с помощью DirectX "уронить" компьютер достаточно легко, т.к., фактически, это способ работать с драйверами почти напрямую. Естественно, вариант ошибки в драйверах на "злосчастном ноутбуке" тоже исключить нельзя.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 20.01.05 15:13
    Оценка: +2
    AVC пишет:

    > Четвертые (и их, кажется, большинство) не могут себе представить

    > создание нового процесса без UNIX-овского примитива *fork()*. (При
    > этом они спокойно пишут многопоточные приложения и вопросов у них не
    > возникает.) В Модуле-2 и Обероне-2 каждый процесс безраздельно владеет
    > своими локальными (стековыми) переменными, а для разделяемых
    > переменных существуют мониторы и семафоры.

    Ах... Как все просто в теории. А теперь к суровой реальности:
    Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
    бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
    ЧТО ставить квоты, явных процессов ведь нет?

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 21.01.05 08:42
    Оценка: -2
    Sergey пишет:

    > C> В винде и юниксах я могу не дать приложению выжрать всю память. А в

    > C> Обероне, видимо, нужно будет ставить квоты на System.Writeln
    > Каким образом можно не дать приложению выжрать всю память в винде,
    > если не
    > секрет?

    Пишем скрипт, который смотрит, чтобы никто не зажирался — нарушителей
    прибиваем.

    > C>>> Точно так же — нужно обеспечить учет дефецитных ресурсов (сетевых

    > C>>> соединений, открытых файлов и т.п.),
    > ??>> С чего бы вдруг сетевым соединениям и открытых файлам быть
    > дефицитными
    > ??>> ресурсами?
    > C> А с того, что их количество ограничено.
    > Чем ограничено? Имеющейся памятью?

    Ограничением архитектуры.

    > C> Еще примеры: открытые соединения к БД, курсоры в БД, графические

    > C> описатели...
    > Ну не стоит экстраполировать свойства ОС, с которым ты знаком, на ОС
    > новые.
    > Я, например, не вижу ни одной причины, по которым количество "графических
    > описателей" (кстати, что это такое и обязательно ли их присутствие в
    > оберонистой ОС?) должно быть ограничено чем-либо, кроме памяти.

    А я вижу. Например, каждый графический объект будет отжирать один
    аппаратный описатель графического ускорителя.

    > C> Ага, принципиальных сложностей нигде нет. А вот реализовать толковый

    > C> механизм разделения привилегий для ОС — ВЕСЬМА непросто.
    > А никто и не обещает, что это просто. Но я вот в упор не вижу, почему
    > замена
    > концепции процесса на концепцию модуля должна как-то повлиять на
    > сложность
    > реализации системы безопасности.

    Потому что модуль — еденица деления КОДА, а процесс — это совокупность
    ПОТОКОВ исполнения кода.

    > C>>> механизмы обхода защиты и т.п.

    > ??>> Нафига нужны механизмы обхода защиты?
    > C> Hint: su, sudo
    > Это, насколько я понимаю, не обход, а просто делегирование части
    > полномочий.

    Это способ обойти защиту для некоторых случаев.

    > C>>> В итоге получится тоже самое, что и в

    > C>>> Юниксе/Винде.
    > ??>> Да ну. Как напишешь, так получится. Может и QNX получиться, может и
    > ??>> BeOS
    > C> Но уж никак не ОС в 50Кб кода
    > Ну в 50Кб кода я тоже не верю А вот дискета-другая — вполне реально.

    Ну так Линукс с несколькими утилитами вполне помещается на дискету.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: DJ KARIES Россия  
    Дата: 22.01.05 22:11
    Оценка: :))
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.


    WH>Думаешь если бы оно было на обероне было бучше


    Однозначно.
    В настоящей Оберон-системе не было бы ни GDI+, ни DirectDraw7, ни Windows XP SP2.
    Ибо нельзя испортить то, что не портится.
    ... << http://dkdens.narod.ru :: http://retroforth.org >>
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 08:55
    Оценка: :))
    Здравствуйте, Cyberax, Вы писали:

    C>А если прибить _НУЖНО_? Например, если, модуль начал неограниченно

    C>отжирать память.

    Э-э-э..., модуль — не обладает "свободой воли" он не может что либо делать. Вот, например, в модуле может быть определена процедура внутри которой может быть код предназначенный для сжирания ресурсов. Так вот, тот кто вызовет эту процедуру — вот он то и будет сжирать, а модуль тут не причем.

    >> 2) Ни потоков, ни процессов в объектно ориентированных операционных

    >> системах не бывает.

    C>Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках —

    C>да, не бывает.

    А чего же Вы тогда так волнуетесь по поводу этих самых недооперационок-то?

    >> Вместо них в объектно ориентированных операционных системах бывают

    >> *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток,
    >> а активный объект (*obj := NIL*).

    C>Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_ ДВЕ

    C>ЗАДАЧИ?

    Каждый активный объект и есть задача. Как объекты создавать надо показывать? Вот так: NEW(obj).
    Re[4]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 13:57
    Оценка: :))
    Здравствуйте, Дарней, Вы писали:

    СГ>>Естественно что невозможно перенести на safe систему unsafe язык программирования. Никаких Си/Си++ под оберонами никогда не будет и ассемблеров тоже, по тойже причине.


    Д>И драйверов к железу тоже никогда не будет?


    Какая связь между языками Си/Си++ и драйверами?
    Драйверы под оберон-системы пишутся на самих оберонах.
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 16:44
    Оценка: +2
    Hello, AVC!
    You wrote on Mon, 24 Jan 2005 16:31:00 GMT:

    A>>> Указатель на видеобуфер, скорее всего, устанавливается в

    A>>> пользовательском модуле, а в одном из модулей ядра. Ядро может быть
    A>>> написано как на Обероне, так и на ассемблере.
    S>> Нестыковка номер раз — утверждается, что ядро может быть написано
    S>> только на обероне.

    A> Ага, понял. Устраивается, так сказать, очная ставка.


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

    A> Ядро может быть написано целиком на Обероне.


    Ответ на этот вопрос зависит от того, есть ли в Обероне низкоуровневые
    средства. Для доступа к памяти и портам ввода/вывода хотя бы.
    Да, а типизация там статическая или динамическая?


    A> Но на практике некоторая (небольшая) часть ядра часто пишется на

    A> ассемблере. Этот код мал, тщательно верифицирован и пишется в
    A> соответствии с требованиями Оберон-системы. Код же расширений системы
    A> пишется программистами на Обероне, чтобы позволить компилятору
    A> контролировать свойства кода. (В принципе, можно представить себе и
    A> создание "песочницы" для других языков: Си, Си++ и т.д. В таком случае
    A> они будут получать доступ к системе не прямо и эффективно, как программы
    A> на Обероне, а через специальный API, как, в принципе, это и делается в
    A> других системах. Так, как и привыкли делать программисты на этих
    A> языках.)

    Ну вот в это я уже верю. Для полного счастья не хватает обхода системы
    типов — чтобы можно было эффективно писать библиотеки ввода.

    A> Низкоуровневый доступ может быть и запрещен при компиляции модулей, не

    A> входящих в ядро. Это зависит от предполагаемого использования
    A> Оберон-системы. Само выделение низкоуровневых средств языка в отдельную
    A> часть, которую можно и не разрешить на определенных уровнях системы, -
    A> хорошая мысль. Такое деление возникло еще в Модуле-2.

    Есть идеи и получше — перенести проверки валидности указателей на уровень
    железа. Как Бабаян предлагает, например. Учитывая, что Intel купила МЦСТ,
    лично мне это представляется более вероятным, чем тотальное нашествие
    Оберон-систем.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 10:21
    Оценка: :))
    Здравствуйте, WolfHound, Вы писали:

    WH>ЗЫ И вобще хватит заниматся всякой фигней типа какой язык из какого что позаимствовал... Все языки что-то заимствовали... Кроме пожалуй чисо концептуальных(на них писать не возможно) и типа BrainFack'а(эти языки еще хуже )


    Заимствование — это неплохо. Даже хорошо. Это форма уважения.
    Проблемы бы не было, если бы Sun вдруг не вздумала скрывать очевидный факт заимствований из Оберона. Какие только фантастические языки не назывались в качестве предшественников Java! А об Обероне — ни-ни!
    А это уже вранье!
    Могу назвать и очевидную цель этого вранья: стать монополистами в этой области.
    Достаточно вспомнить поведение что Sun, что Microsoft во время их исторического судилища.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[13]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 12:24
    Оценка: +1 :)
    Здравствуйте, Cyberax, Вы писали:

    C>Вдогонку, попытался вникнуть в этот тест. Результат: ну и &%@#&$% же

    C>это. Строки используются C-шные, без всякой оптимизации. Большую часть
    C>времени в func0 тратится на strcmp и т.д. Простая замена Сшных строк на
    C>что-нибудь поприличнее даст еще больший прирост скорости.

    C>Работу с массивы можно тоже пооптимизировать (boost::multi_array — наш

    C>друг).

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

    Например, именно поэтому нельзя написать исходник Drystone для Component Pascal — буквальный перевод со старого Паскаля невозможен (не будет компилироваться), а "вольная интерпретация" превращает его в другой тест не имеющий признанного статуса теста Drystone.
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 26.01.05 04:47
    Оценка: +1 :)
    Здравствуйте, AVC, Вы писали:

    AVC>Затем запускал GC и проверял состояние кучи.

    AVC>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.

    Вах-вах, как любопытно. То есть GC взял да и прибил объект, на который остались живые ссылки?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.01.05 10:34
    Оценка: +1 -1
    Здравствуйте, Cyberax, Вы писали:

    C>==============================

    C>List list=new ArrayList();
    C>while(true)
    C>{
    C> list.add(new String("Blah-blah"));
    C>}
    C>==============================
    C>Аналог этого кода на Обероне оставляю в качестве упражнения читателю.

    C>GC никогда не соберет список, так как он не является мусором.



    Вы сделали ошибку под названием "бесконечный цикл". При чем тут GC? Или Вы полагаете, что без него этот код вдруг перестанет содержать ошибку бесконечного цикла?

    Вот корректный код:
    PROCEDURE Do (N: INTEGER);
    VAR list: List; i: INTEGER;
    BEGIN
      NEW(list);
      FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END
    END Do;

    Не смотря на то что переменная list располагается на стеке, и, в придачу, при завершении процедуры не производится явного присваивания list := NIL; GC все равно освободит всю память занимаемую списком.
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 26.01.05 13:21
    Оценка: +2
    Здравствуйте, prVovik, Вы писали:

    V>Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.


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

    Если я не ошибаюсь, именно это долго и безуспешно пытаются донести до фанатов Оберона другие участники дискуссии.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[53]: А если подумать?
    От: Sergey Россия  
    Дата: 27.01.05 14:57
    Оценка: +2
    Hello, Сергей!
    You wrote on Thu, 27 Jan 2005 14:23:58 GMT:

    S>> Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро,

    S>> ядро прибиваем нафиг?

    СГ> А что, страшно, да?


    Конечно.

    СГ> Подумаешь, перезапустим пару-тройку системных объектов...


    Ну, давай перезапустим подсистему, аналогичную виндовской user или gdi.
    Заодно придется перезапускать все программы, которые их используют. Для
    юзера это ничем не будет отличаться от перезагрузки системы.

    СГ> Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и

    СГ> кричите: "Этого не может быть потому что этого не может быть никогда!"

    Да почему же не может? Как раз в падучесть систем без разделения адресных
    пространств я вполне верю

    СГ> Операционка и ее приложения целиком пишутся на ЯВУ Active Oberon и

    СГ> исполняются в одной и тойже среде исполнения. Рантайм система не видит
    СГ> разницы между объектами операционки и объектами приложений.

    Тем хуже для нее.

    СГ> Модули самой ОС с точки зрения рантайм системы ни чем не отличаются от

    СГ> модулей приложений.

    Тоже фигово.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[62]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 28.01.05 11:15
    Оценка: :))
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Класс!

    ЗХ>Даже если это и анекдот, то великолепный!
    ЗХ>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )

    I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.

    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 29.01.05 10:08
    Оценка: +2
    Сергей Губанов пишет:

    > C>Запускающийся независимо от желаний приложения, и работающий сколько

    > ему
    > C>захочется...
    > C>Синхронный GC запускается явно по требованию.
    > Вопрос.
    > Можно ли каждый вызов инструкции NEW(p); считать как завуалированное
    > требование вызова GC?

    Конечно, можно. Оно, кстати, часто так и делается (оператор new —
    замечательный safepoint для GC).

    Вот только в realtime-системах нужно обеспечить ЖЕСТКУЮ гарантию на
    время исполнения new. И вариант "от секунды до часа, как Бог пошлет" —
    не подходит.

    > Ведь, по идее, если мы не вызываем NEW(p), то зачем GC

    > напрягаться-то(???), он может спокойно курить... а вот как только мы
    > вызвали NEW(p), так он сразу — если есть память, то мгновенно ее
    > возвращает, а если нет, то тут он напрягается, трудится-работает
    > убирает мусор, как только уберет сколько затребовали, возвращает ее и
    > дальше курит...

    Именно ЭТО в realtime-системах и неприемлимо. По определению.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 17:33
    Оценка: +2
    Здравствуйте, AVC, Вы писали:

    AVC>На всякий случай, расскажу еще раз, что когда-то был приятно удивлен, узнав, что матрицы в Обероне могут иметь произвольное число столбцов, в отличие от Си, Си++ и Паскаля.

    AVC>Например:
    AVC>
    AVC>TYPE Matrix = ARRAY OF ARRAY OF REAL;
    AVC>


    В Quick/Visual Basic тоже
    Кстати, а это именно прямоугольник, или массив с рваным краем (jagged array) ?
    Потому что рваный край — в С++ делается просто: vector<vector<T> >
    Впрочем, написать класс матрицы и вообще гипер-кирпича с переменными размерами — тоже как два пальца об асфальт.

    Кстати. То, что в С++ это делается не на уровне языка, а с помощью библиотек (в Фортране, кстати, тоже; без библиотек Фортран был бы нищ, как полковник Кудасов), — содержит большое достоинство.

    Дело в том, что в разных случаях удобно и выгодно использовать разное внутреннее представление — разреженные массивы, с перестановкой, с линеаризацией по тому или иному индексу...
    Унифицированный интерфейс позволяет применять к разным реализациям одни алгоритмы.
    А если какое-то представление оказалось зашито в язык, то оно ставит остальные в неравные условия перед разработчиком алгоритмов.
    Перекуём баги на фичи!
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 09.02.05 11:21
    Оценка: +2
    Здравствуйте, AVC, Вы писали:

    AVC>По сути дела, я осознал, что был не вполне прав, когда внушал Cyberax'у, что между bool и float нет ничего общего.

    AVC>Это общее есть, и это общее — (дурацкая, все-таки, прости Господи! не могу больше молчать! ) манера писать на Си выражения вида if (x) для произвольного типа.
    AVC>В нормальных языках пишут что-то вроде
    AVC>
    AVC>if (x != 0.0)
    AVC>

    AVC>или
    AVC>
    AVC>if (p != NULL)
    AVC>

    AVC>и т.п.

    Абсолютно согласен! if(p) для небулевских типов (т.е. для которых приведение к bool не сделано осмысленно) — весьма дезинформирующая штука.
    Перекуём баги на фичи!
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 17:03
    Оценка: :))
    Здравствуйте, Cyberax, Вы писали:

    >> А вот то, что в Си++ это *не* сделано на уровне языка — явный недостаток.

    C>А зачем это на уровне языка? И почему на уровне языка должны быть именно
    C>прямоугольные массивы, а не разреженные матрицы в виде мультисписков?
    C>Чем прямоугольники лучше?

    Просто есть базовые конструкции. То, из чего конструируются все остальные.
    Например: массивы, структуры, указатели на них.
    А есть сложные динамические структуры, которые из них строятся.
    Как правило, они используются для представления АТД, создаваемых программистом для решения конкретной задачи.
    А еще есть некоторый логический порядок абстракций.
    Например, сначала целые числа, затем вещественные, затем — комплексные.

    >> К>А если какое-то представление оказалось зашито в язык, то оно ставит

    >> остальные в неравные условия перед разработчиком алгоритмов.
    >> Просто доведите это свое утверждение до логического конца.
    >> Вы придете к языку ассемблера.
    C>Ну так C и создавался как низкоуровневый язык, ближайшая замена
    C>ассемблеру. На а С++ унаследовал (частично) дух С.

    Об этом я и говорю.
    А то некоторые утверждают, что Си++ — сильно типизированный язык.
    Тогда как отовсюду "торчит" Си.
    Только Си — простой, маленький и честный язык.
    А Си++ пытается усидеть на всех стульях сразу.
    Он и седалище себе соответствующее отрастил.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[20]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 16.02.05 10:01
    Оценка: -2
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Как интересно в Си/Си++/Java/C# работают с битами? Наверное там битовые операции применяют прямо к числам? Вот несчастные программисты, как они там мучаются — ведь в Си/Си++/Java/C# множество битов и числа — это одно и тоже, хотя спроси любого математика так он ответит, что число — это одна математическая абстракция (теория чисел), а множество — совсем другая (теория множеств).


    К тому же еще если для битовых операций использовать числа, то программа будет не переносимой между big и little endian архитектурами процессоров.
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 16.02.05 15:15
    Оценка: +1 :)
    AVC пишет:

    > Справедливости ради, матричная алгебра на Обероне реализуется проще,

    > чем на Си++.

    Агащаз... А как насчет разреженных матриц, например? Причем с прозрачным
    для пользователя механизмом переключения представления матрицы
    (мультисписок->jagged array->flat array). Чего-то не вижу никакой особой
    поддержки языка в этом.

    > Причина: отсутствие в Си++ многомерных гибких массивов.


    Нафиг они не нужны для библиотеки лин. алгебры.

    > К>А между прочим, она уже давным-давно реализована на уровне языка:

    > смотри APL, MatLab.
    > К>Я даже не прошу тензорную алгебру, бог с ней, она не часто нужна, да
    > и размерности там офигительные. Хотя в минимальном виде (аффиноры)
    > можно было бы.

    Еще один частный случай очень редко используемой фичи добавлять в язык?
    Ну-ну...

    > К>А куда делись столь нужные 3D-моделистам кватернионы?

    > К>И после этого ты ещё осмеливаешься хвалить Оберон?
    >
    А в С++ это все можно

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 16:39
    Оценка: :))
    Здравствуйте, Cyberax, Вы писали:

    >> Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь

    >> белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на
    >> глаз и на ощупь.
    C>Да я понял. Я вроде бы никогда не утверждал, что С++ — это простой язык
    C> Но фичастый — это точно.

    Я не со зла.
    Просто хотелось так: Cyberax попадается в ловушку, тут появляюсь я и грозно спрашиваю:

    Ну, теперь понял, что я имею в виду?

    Но тут пришел Павел Кузнецов и весь праздник испортил.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 18.02.05 16:00
    Оценка: +2
    AVC пишет:

    > C>операции над таким составным множеством?

    >
    > Примерно так:
    >
    >DEFINITION BitSets;
    >
    >TYPE
    > BitSet* = RECORD
    > size-: INTEGER; (** число элементов в битовом множестве *)
    > PROCEDURE (VAR set: BitSet) Init*(size: INTEGER);
    > PROCEDURE (VAR set: BitSet) Incl*(bit: INTEGER);
    > PROCEDURE (VAR set: BitSet) Excl*(bit: INTEGER);
    > END;
    >
    >END BitSets.
    >
    И чем это отличается от std::set, кроме отсутствия поддержки стандартных
    алгоритмов, итераторов, и удобного доступа?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 22:57
    Оценка: 21 (1)
    Здравствуйте, Кодт, Вы писали:

    К>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Можно, но надо-ли?


    К>Я уже говорил, что операции над голыми типами — это возможность накосячить.

    К>Пример с данным кодом:
    К>
    К>TYPE LongSet = ARRAY OF SET;
    К>PROCEDURE SetAdd(VAR dst: LongSet; x: INTEGER);
    К>PROCEDURE SetUnion(a,b: LongSet; VAR dst: LongSet);
    К>PROCEDURE SetCross(a,b: LongSet; VAR dst: LongSet);
    К>PROCEDURE IsEmptySet(a: LongSet): BOOLEAN; (* проверяет, что вектор заполнен пустыми множествами *)
    К>PROCEDURE CompactSet(VAR dst: LongSet); (* отбрасывает хвост массива, заполненный пустыми множествами *)
    К>.....
    
    К>TYPE StackOfSets = ARRAY OF SET; (* другой логический смысл такого же контейнера *)
    К>PROCEDURE PushSetIntoStack(VAR stack: StackOfSets; item: SET);
    К>PROCEDURE PopSetFromStack(VAR stack: StackOfSets; VAR item: SET);
    К>PROCEDURE IsEmptyStack(stack: StackOfSets): BOOLEAN; (* проверяет, что размер равен нулю *)
    К>.....
    
    К>VAR x: LongSet;
    К>    y: StackOfSets;
    К>BEGIN
    К>  ...
    К>  PushSetIntoStack(x, {0,1,2} ); (* Перепутали x и y. Компилятор сожрал. *)
    К>  ...
    К>END;
    К>


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

    К>В некоторых, критичных, местах бывает полезно даже числовые типы заворачивать в классы, чтоб с размерностями проблем не было.

    К>(В С++ это проще, там есть перегрузка операторов; но это так, к слову).

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

    B.3 Abstract Operators

    Oberon supports the definition of abstract data types but lacks a corresponding support for the definition of abstract infix operators. This is unfortunate, because the ordinary procedural notation is clumsy in combination with nesting. Therefore, we allow the overloading of operators by redefinition. Syntactically, a redefinition is identical to a procedure declaration, where the procedure name is replaced by the operator symbol, for example by "*". It should be noted that the identification of operators in the context of an expression is done at compile time, that is, it does not depend on the dynamic types of the operands. The identification algorithm is: (a) identify all matching declarations, i.e. declarations whose formal parameter types are (direct or indirect) base types of the corresponding actual parameter types and (b) select the matching operator that lexicographically minimizes the "type-distance vector", where the components of this vector are the level differences of actual type and corresponding formal type from left to right. Typically, Oberon does not allow structured types for function return values. In the interest of nestable abstract operators, this restriction is removed in our extended compiler.

    Syntax:

    ProcDecl = PROCEDURE {ProcTags} (IdentDef | '"'OpDef'"' ["*"])
    [FormalPars] ";" Scope (ident | '"'OpDef'"').
    OpDef = Relation | AddOp | MulOp | "~".
    Relation = "=" | "#" | "<" | "<=" | ">" | ">=" | IN.
    AddOp = "+" | "-" | OR.
    MulOp = " * " | "/" | DIV | MOD | "&".

    Example:

    TYPE
    A = RECORD ... END;
    B = RECORD ... END;
    A1 = RECORD (A) ... END;
    B1 = RECORD (B) ... END;

    PROCEDURE "*" (a: A; b: B): A;
    BEGIN ... (* implementation 1 *)
    END "*";

    PROCEDURE "*" (a: A1; b: B): B1;
    BEGIN ... (* implementation 2 *)
    END "*";

    PROCEDURE "*" (a: A1; b: B1): B;
    BEGIN ... (* implementation 3 *)
    END "*";

    VAR a: A; b: B; a1: A1; b1: B1;

    a*b identifies implementation 1
    a1*b identifies implementation 2
    a*b1 identifies implementation 1
    a1*b1 identifies implementation 3
    (a*b)*b identifies implementation 1 twice
    a1*(a1*b1) identifies implementations 3 and 2

    В принципе, я почти на каждую интересную возможность Си++ мог бы отвечать: это есть и в Обероне.
    Есть даже Обероны с шаблонами (как правило этакие "кросс-Обероны" с компиляцией в Си/Си++).
    Но так как этих возможностей нет в стандарте Оберона (Oakwood guidelines), то я так не отвечаю, а пытаюсь понять, почему этого нет в стандарте.
    Возможно, одна из причин в том, что оберонщики стремятся сохранить свой язык маленьким (минимализм).
    (Для Си, например, священной коровой является свобода программиста.)
    Особо меня интересует возможность использования шаблонов/дженериков в Обероне, чтобы, например, избежать ситуации безтиповых универсальных контейнеров (как в Java).
    Объяснение отсутствию в Обероне шаблонов в духе Си++ (template) я нахожу в том, что они противоречат раздельной (separate) компиляции.
    Дженерики, думается, в Обероне вполне возможны. Ведь именно в Обероне стали использовать промежуточный код для переноса модулей между разными системами. Так что в .NET Оберон несомненно впишется. Не зря, наверное, Microsoft финансирует проект Zonnon. (А Intel, к слову, участвует в образовательном проекте Информатика-21, о котором говорил Сергей.)
    Но меня сейчас интересует "вырожденный" случай.
    Предположим, я не хочу напрягаться с JIT-компиляцией, а только хочу обеспечить типобезопасность использования универсальных контейнеров. Для простоты будем полагать, что в контейнеры помещаются только указательные типы. (Во многих языках и выбора-то нет, в той же Java.)
    В качестве примера рассмотрим список.
    MODULE Lists;
    TYPE
      List = POINTER TO ListNode;
      ListNode(T) = RECORD
        data: T;
        next, prev: List;
      END;
    А где-то в прикладном модуле можно было бы написать так:
    TYPE
      Foo = POINTER TO FooDesc;
      FooDesc = RECORD ... END;
    VAR
      FooList: Lists.List(Foo);
    Я, конечно, привожу только набросок, в нем могут быть какие-то несогласованности.
    Каковы, ИМХО, существенные моменты?
    1) Нет никакого противоречия с раздельной компиляцией.
    Модуль Lists может спокойно пребывать в виде объектного кода.
    Для него T — это всего лишь PTR (как в ETH Oberon) или ANYPTR (как в BlackBox).
    Если требуется что-то иное (не PTR), можно было бы писать что-то вроде
    ListNode(T: NeededType) = RECORD ... END;
    чтобы обозначить, что элементом может быть только NeededType или его потомки.
    2) Вся "нагрузка" ложится на компиляцию клиентского модуля.
    Но сводится она только к статическому контролю типов типов и, возможно, автоматической вставке в отдельные места type guard.
    3) Как мне кажется, к большому усложнению компилятора это не должно привести.
    Так что он останется вполне в рамках минимализма.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 20:53
    Оценка: 17 (1)
    Здравствуйте, Astaroth, Вы писали:

    AVC>>>>В принципе, Си++ — язык для детской песочницы.

    WH>>>Такое себе даже фанаты C# не позволяют.
    AVC>>Зато позволяют себе правительства Канады и Великобритании.
    A>Тогда прошу предъявить мне либо ссылку, где правительства Канады и Великобритании заявляют, что "Си++ — язык для детской песочницы", либо доказательства того, что AVC является правительством Канади и Великобритании


    Пожалуйста:

    That is where we learned that Canada and the UK (and probably other countries as well) strictly prohibit the use of C and C++ for developments related to any nuclear application.

    Там же можно отыскать такую любопытную цитату:

    At this conference, Dr. Clemens Szyperski also gave a memorable speech about the relationship between the tools and programming languages used and the quality and reliability of the code produced.

    A famous quote (from memory): "It is a matter of disbelieve that so many people insist on using a fundamentally flawed tool for the most complex jobs that humanity ever had to face."

    Надеюсь, Клеменса Шиперски представлять не нужно?
    http://www.amadeus-3.com/main_files/space.html
    Были и другие источники, да только память у меня девичья.
    В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.
    С ним можно не соглашаться, но почитать его опусы стоит (imho).
    Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
    Лично мне наиболее интересной кажется статейка
    http://www.amadeus-3.com/main_files/FlawsOfCPP.php
    но можно почитать и
    http://www.amadeus-3.com/main_files/oberon2vsCPP.php

    Что же касается Си++, то на практике я отношусь к нему вполне лояльно.
    В большинстве своих проектов я использовал именно этот язык, и знаю его достаточно хорошо (конечно, не как Павел Кузнецов ).
    Так что моя "критика" — совсем не вопли злобного "аутсайдера".
    Но именно поэтому я не могу не чувствовать внутреннего напряжения, нарастающего в языке.
    Стали заметны нестыковки, ограничения (explicit), ограничения ограничений (mutuable), "подпружные арки и контрфорсы".
    Главное: инструмент перестал умещаться в руке.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 11:20
    Оценка: 12 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    К>>Даже в Turbo Pascal 3 было 256...

    СГ>Зато работает быстрее, т.к. 256 битов в одном регистре не убираются, а 32 бита убираются.

    Если в паскале указать set of 0..31, то тоже в дворд влезет

    На самом деле, после прочтения статьи Вирта, я понял, зачем так сделано.
    Поддержка битовых флагов — конечно, нужна; но обобщать её до set of any_range — это большие накладные расходы:
    1) либо всё впихивается во всеобъятный set of byte, — оверхед по памяти и по обработке,
    2) либо создаётся семейство безымянных типов — диапазоны/перечисления и множества над ними — а это усложнение компилятора

    Поэтому общепринятые 32-битные флаги, оформленные как отдельный тип — это такой хороший компромисс.
    Теперь вместо булевой алгебры над числами как битовыми векторами (сишные &, |, ^, ~ и соответствующие паскалевские операции) используются эквивалентные теоретико-множественные действия — это, как правило, нагляднее, а значит, и ошибкоустойчивее.

    Ну а реализация действительно больших множеств — это предмет исследования в каждом конкретном случае.
    Битовый вектор — ARRAY(n) OF SET — одно из возможных, но необязательно самое эффективное представление. Например, если универсум — это все целые числа, то размер такого вектора будет 2^29 байт. Восемь векторов, и адресное пространство кончилось
    Перекуём баги на фичи!
    Re: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 10:15
    Оценка: 6 (1)
    Неделю назад, буквально за минуты до падения сервера, хотел написать: как наглухо зацепиться за стек и подгадить GC.

    Идея состоит в следующем.
    Пусть некий активный объект владеет стеком своего потока (ну и далее оттуда растёт орграф зависимостей).
    Теперь достаточно в одной из функций подцепить указатель на сам объект и уйти в бесконечность. Всё, мы получили вешалку, за которую можно цеплять что угодно (например, активный объект содержит коллекцию указателей на сторону).
    Кстати, скорее всего, объект с самого начала зацеплен за стек своего потока.

    Разумеется, можно обнаружить, что часть объектов недоступна из корня орграфа (корнем является стек главного потока). Тогда встанет вопрос: а как же грамотно убить сирот? Пассивный объект — нет проблем: разорвали граф, поубивали участников. Но у активного графа есть действующий поток, как его останавливать?

    Кстати о бесконечном цикле.
    Разумеется,
    while(evertrue()) { ..... }

    является ошибкой в данном конкретном месте программы.
    Однако можно же сделать и по-другому:
    take(semaphore, INFINITE);

    а клиент забудет выполнить действия, приводящие к give.

    За неимением оберона, ставил эксперименты на python. Единственный способ замочить забытый поток — это послать интерпретатору сигнал term или kill.
    from threading import *
    
    class Orphan(Thread) :
      name = ""
      evt = 0
      def goodbye(self) :
        self.evt.set()
      def __init__(self,n) :
        Thread.__init__(self)
        self.evt = Event()
        self.name = n
      def run(self) :
        print self.name,"started"
        self.evt.wait()
        print self.name,"finished"
    
    def fire(n) :
      t = Orphan(n)
      t.start()
      return t
    
    # запустили...
    t1 = fire("First")
    t2 = fire("Second")
    # отсигналили только одному
    t1.goodbye()
    #t2.goodbye()
    # потеряли указатели
    t1 = 0
    t2 = 0
    print "The end"
    Перекуём баги на фичи!
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 26.01.05 06:34
    Оценка: 3 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...


    Я бы сказал немного по другому — в определенной (очень узкой) области такая замена приемлема.
    Для десктопа и уж тем более серьезных серверных приложений падение безопасности будем неприемлемым, а вот для встроенных устройств и прочих девайсов с ограниченными ресурсами — в самый раз.
    Так что прямой конкурент для ОберонОС — это не Windows и Linux, а Symbian. Надо признать, что и здесь googlewar показывает разгромное поражение Оберона: http://googlewar.com/search.cfm?q1=Oberon+OS&amp;q2=Symbian
    Или все-таки у него есть какие-то преимущества?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 15:52
    Оценка: 3 (1)
    Здравствуйте, Privalov, Вы писали:

    P>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.


    Т.е. если надо долбить стену...
    Шутка.

    P>Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.


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

    P>Вирт стремится создать идеальную систему. Здесь можно прочитать о проектах, над которыми он работал. Немногие из них дошли до нас в первозданном виде. (В тот год, когда я стал студентом, обучение программированию стало вестись на базе Фортрана, до этого оно велось на базе алгола. Не думаю, что это наш курс повлиял).


    Вирт стремится создать надежный (а не идеальный) язык программирования.
    Одна из причин такого его желания изложена здесь:
    http://www.inr.ac.ru/~info21/info/wirth_avia.htm
    Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.
    Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
    Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

    P>Страуструп, напротив, практик. Его место работы, можно сказать, КБ или отраслевой НИИ. Основная задача таких организаций — воплощение в жизнь теорий, создаваемых академиками. Где-то на этом форуме уже обсуждалась подобная тема.


    Напротив?!
    (Т.е. Вирт — не практик, что ли?)
    Страуструп — практик?!
    Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.
    Да и тот давно уже создается огромным комитетом...

    P>Работа Вирта дала материал для размышления многим, в том числе Страуструпу. Однако, прагматизм последнего (вольный или невольный), несомненно, сыграл свою роль в том, что C++ распространен гораздо шире, чем любой из проектов Вирта.


    Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 20:57
    Оценка: 3 (1)
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>>>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.

    AVC>>>>Программист — человек. Он может ошибаться.
    AVC>>>>А вот что делать компилятору и отладчику?
    RRM>>>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.
    AVC>>Опаньки!
    AVC>>Куда ему, компилятору.
    AVC>>Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками?
    RRM>Нет не отрицаю, но при этом не вижу смысла забирать низкоуровневые возможности.

    Низкоуровневые возможности (low-level facilities) иногда совершенно незаменимы.
    Но они таят в себе опасность, т.к. программист отключает "автопилот" системы типов.
    В Обероне низкоуровневые средства языка используются, в основном, в небольшом числе модулей, относящихся к операционной системе. Такие модули легко распознаются по импорту модуля SYSTEM.
    В Си использование низкоуровневых средств языка разбросано по всему коду. Например, любая передача указателя в качестве параметра чревата неверным его использованием.
    Искать ошибки (особенно случайные) в таких условиях гораздо труднее.

    AVC>>Никто не отрицает потребности в низкоуровневых средствах.

    AVC>>Но нельзя же превращать весь язык в одно низкоуровневое средство!
    AVC>>В Обероне есть четкое различие: "импорт" SYSTEM.
    AVC>>А в Си низкоуровневые средства "заполонили" весь язык.
    RRM>А С и разрабатывался как алтернатива ассеблеру. Кстати есть С++, и там вас никто не вынуждает использовать массивы, есть например vector<> + все нискоуровневые возможности С.

    Мне кажется, что мы говорим не совсем об одних и тех же вещах.
    Как будто мы испольуем одни и те же слова, но вкладываем в них разный (отчасти?) смысл.
    Возможно, нам надо просто уточнить терминологию, и, может статься, выяснится, что в принципе мы согласны.
    Попытаюсь проиллюстрировать свою мысль на примере этого Вашего предложения.
    Вы говорите, что в Си++ необязательно использовать массивы, а можно использовать векторы или другие контейнеры STL.
    У меня складывается впечатление, что Вы (почти) отождествляете адресную арифметику и массивы.
    Если это так, то во многом проясняется причина "дискуссии".
    В Си++ использование "сишных" массивов действительно считается средством низкого уровня.
    Ведь в Си выражение a[ i ] == *(a + i) == *(i + a) == i[a].
    Т.е. это частный случай применения адресной арифметики.
    Возможно, Вы и говорите просто об употреблении массивов, и удивляетесь, как это я без них обхожусь.
    А я и не обхожусь, ни на Си, ни на Обероне.
    Просто на Обероне использование массива не является низкоуровневой конструкцией, и полностью контролируется компилятором. (Вот в чем значение избыточности. Массив в Обероне — везде массив. А не какой-то там указатель. )
    Почти то же самое бывает и в Си. Например:
    void foo()
    {
        int i, a[10];
        for (i = 0; i < 10; ++i)
            a[i] = i;
        bar(a);
    }
    Здесь компилятор точно знает, что имеет дело с массивом, и может не допустить обращение к элементу массива с недопустимым индексом.
    Но стоит передать этот массив в качестве параметра, вся эта информация теряется.
    Уже в функции bar все выглядит по-другому.
    void bar(int *a)
    {
    }
    Что такое здесь a? Массив? Адрес скалярной переменной? Адрес объекта кучи?
    Компилятор не знает. А значит не может контролировать корректность действий программиста.
    Именно поэтому использование массивов в Си (как и весь язык в целом) относится к низкому уровню.

    RRM>Согласитесь, что вы не против адресной арифметики, а против ее повсеместного и неуместного применения.


    Согласен.

    RRM>Еще мне кажется, что использование адресной арифметики в стиле С несколько проще, чем модуля SYSTEM (по крайне мере там, где это необходимо)


    Вероятно, это вопрос привычки.
    Я, например, действительно привык к адресной арифметике в Си.
    Первое время именно использование модуля SYSTEM мне давалось с некоторым усилием.
    Рука "сама" выводила Си-подобные конструкции.
    (Интересно, что программирование без использования SYSTEM не вызвало у меня ни малейших затруднений.
    Начал писать на Обероне с первого дня знакомства с ним. Причем не Out.String("Hello, world!"), а сразу системы линейных уравнений и т.п. То ли Оберон соответствует моей интуиции, то ли сказывается его систематическая простота.)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[3]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 24.01.05 09:02
    Оценка: 1 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Только всяких Оберонов много: Oberon, Oberon-V, Object Oberon, Oberon X, Active Oberon, Oberon SA, Oberon-2, Concurrent Oberon, Action Oberon, Oberon-D, Component Pascal, Active Oberon for .net, Zonnon, то есть вовсе не обязательно использовать именно Оберон-2.


    ты считаешь это плюсом?

    СГ>Естественно что невозможно перенести на safe систему unsafe язык программирования. Никаких Си/Си++ под оберонами никогда не будет и ассемблеров тоже, по тойже причине.


    И драйверов к железу тоже никогда не будет?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 14:24
    Оценка: 1 (1)
    Hello, Сергей!
    You wrote on Mon, 24 Jan 2005 13:57:59 GMT:

    Д>> И драйверов к железу тоже никогда не будет?


    СГ> Какая связь между языками Си/Си++ и драйверами?

    СГ> Драйверы под оберон-системы пишутся на самих оберонах.

    Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF. Требуется
    установить байт 0xE4000040 в 0xCE, шоб точку на экране показать. Как это
    сделать, принимая во внимание, что "вопрос "...менять содержимое памяти,
    принадлежащей другому приложению" не имеет физического смысла, поскольку в
    языке нет способа узнать что-либо про память, нельзя получить численное
    значение указателя (указатель — вещь в себе, его численное значение, если бы
    его можно было бы получить, оказалось бы вовсе не константой, а то и дело
    изменялось бы благодаря стараниям сборщика мусора)."?

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[8]: Как пишут драйверы на safe языках программирования.
    От: Privalov  
    Дата: 25.01.05 09:15
    Оценка: 1 (1)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>А) В Оберонах: никогда не пользуйтесь чужими непроверенными программами импортирующими модуль SYSTEM.


    СГ>Б) В Си/Си++/Assembler.... и т.д.: никогда не пользуйтесь вообще никакими чужими непроверенными программами.


    Microsoft Office в Windows относится к проверенным программам? А модуль SYSTEM в Обероне? О какой безопасности вообще идет речь, если импорт модуля SYSTEM уже представляет определенную угрозу (по крайней мере, я так понял Вашу рекомендацию).
    Re[50]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 27.01.05 05:45
    Оценка: 1 (1)
    Здравствуйте, Cyberax, Вы писали:


    C>Я привел пример кода, который вызовет ошибочную ситуацию в системе. В

    C>обычных ОСах система может просто прибить процесс, который эту ситуацию
    C>вызвал (у всех процессов — разные адресные пространства), но в ОберонОС
    C>этого сделать нельзя — так как нельзя автоматически определить какие
    C>объекты являются мусорными. Прибивать произвольные объекты тоже нельзя —
    C>нарушится ссылочная целостность.

    А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 13:40
    Оценка: 1 (1)
    Здравствуйте, AVC, Вы писали:

    AVC>Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.)


    Ересь какая...
    Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон. Для "множественности" придумано ООП. Создаете столько объектов сколько хочется и работаете с этим множеством контекстов. А модуль — это всего лишь вместилище кода, который сам по себе "не обладает свободой воли".

    AVC> И никаких проблем со статическими указателями!


    А проблем и так нет.
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 14:20
    Оценка: 1 (1)
    Здравствуйте, AVC, Вы писали:

    КЕ>> ну вы блин даете...

    КЕ>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

    AVC>Видно, возмущение было столь сильным, что на критику уже слов не хватило?


    На самом деле, возмущение справедливое.

    1) Если предусмотрено приведение к нескольким разным типам, то по можно предположить, что полученные значения коррелируют. Например, контейнер строки может отдавать const char*, bstr_t и т.п.
    В тех же случаях, где результат серии преобразований носит разрушительный характер, то лучше избегать неявностей.
    Кстати, отчасти поэтому в С++ введены две фичи:
    * не более одного неявного преобразования в выражении
    * явные (explicit) конструкторы

    2) Практика показывает, что приведение к bool носит двоякий характер:
    * по смыслу — проверка валидности, непустоты и т.п.
    * по форме — сравнение с нулём.
    В случае числовых типов сравнение с нулём обычно определено; поэтому вводить дополнительно operator bool(), несущий иной смысл — это рассогласовывать форму и содержание.

    3) Операторы неявного приведения типа нужны для
    * уменьшения писанины (применения функций/методов/операторов явного приведения)
    * единообразия (особенно, при подстановке в шаблоны)
    Но поскольку для встроенных типов приведение к bool — это проверка на 0, то кардинально иной смысл приводит к нарушению работы алгоритма. Вместо этого лучше параметризовать алгоритм предикатом.
    В случае с Float — нужен ли был этот оператор, или просто руки шаловливые оказались?

    Пример кода
    float x;
    Float X;
    
    if(x) { ... } // если y != 0
    if(X) { ... } // если x валидный? если x != 0?
    
    if(x!=0) { ... } // предположительно, здесь компилятор может оптимизировать, увидев литеральный 0
    if(X!=0) { ... } // возможно, что сравнение с целым нулём - дороже, чем просто проверка на 0
    
    if(is_nonzero(x)) { ... } // инлайнится в y!=0
    if(is_nonzero(X)) { ... } // эффективная реализация предиката - на усмотрение разработчика
    
    if(is_valid(x)) { ... } // если такие задачи встречаются, то можно реализовать.
    if(is_valid(X)) { ... } // явная замена двусмысленному operator bool


    4) Наконец, компилятор VC даёт предупреждение о приведении к bool и из bool в число. (Про другие компиляторы — врать не буду). Кому хочется развлечений — включайте опцию "treat warnings as errors" и наслаждайтесь.
    Перекуём баги на фичи!
    Re[60]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 10.02.05 18:01
    Оценка: 1 (1)
    Здравствуйте, AVC, Вы писали:


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

    AVC>Вы тогда упоминали дженерики в C# 2.0.
    AVC>Но там требовалась JIT компиляция.
    Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).
    Просто их можно легко использовать из MSIL кода так как они в отличие от шаблонов "Типизированы". То есть неопределенный тип должен поддерживать наложенные на него ограничения ввиде интерфейсов, делегатов итд.
    Так, что по аналогии с dcu из них легко сгенерить код под определенный тип.
    Если образно сравнивать шаблоны и дженерики то в первом случае это позднее связывание а дженерики раннее.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Kh_Oleg  
    Дата: 17.02.05 09:16
    Оценка: 1 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

    ПК>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

    Шикарнейший язык!

    ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

    Читал, много думал...
    Почему взятие итераторов в скобки меняет смысл объявления?
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 17.02.05 14:03
    Оценка: 1 (1)
    Kh_Oleg,

    > На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции".

    > Но вот в случае с глобальными переменными ситуация меняется.

    Я позволю себе подкатить бочку еще немного в направлении C++: в функциях (в т.ч. и в функциях-членах) объявлять функции можно
    Автор: Павел Кузнецов
    Дата: 03.08.02

    #include <list>
    #include <iterator>
    
    using namespace std;
    
    int main()
    {
         list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>()); // те же пироги
         return data.empty(); // oops... "нельзя применить точку к функции"
    }

    Это пришло еще из C, где объявление функции внутри другой функции означало, что функция определена в окружающей области видимости. И, таки да, с этим можно встретиться в реальной жизни:
    http://rsdn.ru/Forum/Message.aspx?mid=453121
    Автор: Павел Кузнецов
    Дата: 24.11.03

    http://rsdn.ru/Forum/Message.aspx?mid=379574
    Автор: Павел Кузнецов
    Дата: 10.09.03

    и т.п.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 16:14
    Оценка: 1 (1)
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Тпру Касте Оберонопочитателей напоминаю, что я ни против Оберона, ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и я" ), так что иронию можно перенацелить на кого-нибудь более враждебно настроенного. В данном случае мне было, действительно, интересно, как же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не написали объявление функции, а не чтобы задеть


    Ну, виноват, прости мерзавца...
    Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на глаз и на ощупь.

    ПК>Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):

    ПК>
    ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );
    ПК>


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

    ПК>

    ПК>(*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил

    Неправда!
    Я хороший! Просто строчку забыл напечатать, а компилятор сильно типизированного языка Си++ и так "сжевал", вот я и не заметил. Должно было быть примерно так:
    #include <fstream>
    #include <list>
    
    using namespace std;
    
    ifstream dataFile("ints.dat");
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
    
    int main()
    {
        return 0;
    }

    Две строки (ifstream и list<int>) позаимствованы у Мейерса ("Эффективное использование STL", совет 6).
    Там он пишет:

    Остерегайтесь странностей лексического разбора Си++.

    Опять фичи, фичи, бесконечные Си++овские фичи...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 19.01.05 13:30
    Оценка: +1
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Privalov, Вы писали:

    AVC>Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"? :-\

    Защита приложений — одна из функций многозадачной операционной системы. При этом не имеет никакого значения, на каком языке программирования реализовано то или иное приложение.
    Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 20.01.05 12:06
    Оценка: +1
    Сергей,

    > В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть. Все что можно сделать с указателем p так это <...> Таким образом, вопрос "...менять содержимое памяти, принадлежащей другому приложению" не имеет физического смысла <...> А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует <...>


    Это в теории. А на практике, как мы выяснили ранее, операции, требующие прямого доступа к памяти, не исчезают, а просто-напросто переносятся с уровня языка на уровень библиотек. Фактически, это означает, что никаких гарантий, что память не будет запорчена, нет. Это, в свою очередь означает, что, в принципе, одно приложение вполне может повлиять на работоспособность всей системы.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 20.01.05 12:32
    Оценка: +1
    Hello, Павел!
    You wrote on Thu, 20 Jan 2005 12:25:06 GMT:

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

    ПК> Потому что на практике системы с разделяемыми адресными пространствами

    ПК> используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием
    ПК> теоретической возможности порчи памяти/whatever...

    Не только. Бага с buffer underflow в csrss.exe обходилась без порчи памяти в
    общем адресном пространстве. Скорее уж можно сказать так "потому что на
    практике все системы имеют ошибки".

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 20.01.05 12:37
    Оценка: +1
    Здравствуйте, Павел Кузнецов, Вы писали:

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


    ПК>Потому что на практике системы с разделяемыми адресными пространствами используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием теоретической возможности порчи памяти/whatever...


    Действительно, о "разделяемых адресных пространствах" можно говорить с известной долей условности. (Раньше эрудиты писали "cum grano salis". )
    Ядро — одно для всех. (Уже одно это должно было бы охладить пыл яростных сторонников отдельных "адресных пространств". )
    Но падает все же система не от этого, а потому что ядро написано с ошибками.
    Кроме того, именно отдельные "адресные пространства" приводят к экспоненциально растущему перерасходу памяти.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 20.01.05 13:52
    Оценка: :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>У меня тоже есть программа (сам написал на Delphi) использует графику GDI+ и DirectDraw7. Так вот, на всех компьютерах работает замечательно, но на ноутбуке шефа при попытке перерисовки мгновенно вываливается в синий экран смерти Windows XP SP2. Вот Вам и виртуальные адресные пространства... Чего я только ни делал пытаясь понять где ошибка. Даже каждую процедуру программы обернул дополнительным блоком try except — бесполезно, ни каких исключений не возникает, моя программа работает корректно, но просто вызывает мгновенную смерть виндос на том злосчастном ноутбуке.


    Думаешь если бы оно было на обероне было бучше
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 20.01.05 17:52
    Оценка: +1
    Sergey пишет:

    > C> Ах... Как все просто в теории. А теперь к суровой реальности:

    > C> Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
    > C> бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
    > C> ЧТО ставить квоты, явных процессов ведь нет?
    > На модули, наверное. Винде, кстати, если выжрать всю память, тоже фигово
    > будет.

    В винде и юниксах я могу не дать приложению выжрать всю память. А в
    Обероне, видимо, нужно будет ставить квоты на System.Writeln

    > C> Точно так же — нужно обеспечить учет дефецитных ресурсов (сетевых

    > C> соединений, открытых файлов и т.п.),
    > С чего бы вдруг сетевым соединениям и открытых файлам быть дефицитными
    > ресурсами?

    А с того, что их количество ограничено. Еще примеры: открытые соединения
    к БД, курсоры в БД, графические описатели...

    > C> изоляцию приложений, работающих с разными привиллегиями,

    > Прям щас пишу поддержку привелегий на уровне объектов для RPC. На С++.
    > Сложности конечно есть, но непринципиальные.

    Ага, принципиальных сложностей нигде нет. А вот реализовать толковый
    механизм разделения привилегий для ОС — ВЕСЬМА непросто.

    > C> механизмы обхода защиты и т.п.

    > Нафига нужны механизмы обхода защиты?

    Hint: su, sudo

    > C> В итоге получится тоже самое, что и в

    > C> Юниксе/Винде.
    > Да ну. Как напишешь, так получится. Может и QNX получиться, может и BeOS

    Но уж никак не ОС в 50Кб кода

    > PS: я не защитник оберона, но, блин, аргументы-то и по толковей найти

    > можно...

    Толковые кончились...

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 21.01.05 10:35
    Оценка: -1
    Здравствуйте, alexeiz, Вы писали:

    A>Даже с закрытыми глазами можно сказать, что это драйвер.


    Спасибо.

    A>Нечего мудрить. Когда система падает, нужно memory dump создавать, потом с ним в отладчик и !analyze.


    Как? Виндос мгновенно грохается, компьютер уходит в перезагрузку. Как вообще что-либо создать если не то что моя программа больше не работает, а сам комп ушел в перезапуск...
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 21.01.05 11:43
    Оценка: :)
    Здравствуйте, Дарней, Вы писали:

    AVC>>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety).

    Д>ОН вернулся... трепещите, несчастные грешники!!! :lol:

    У-у, горе вам, поклонники Си++...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[2]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 08:33
    Оценка: :)
    Здравствуйте, Borisman2, Вы писали:

    B> Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту.


    Ну наконец-то!

    Только всяких Оберонов много: Oberon, Oberon-V, Object Oberon, Oberon X, Active Oberon, Oberon SA, Oberon-2, Concurrent Oberon, Action Oberon, Oberon-D, Component Pascal, Active Oberon for .net, Zonnon, то есть вовсе не обязательно использовать именно Оберон-2.
    http://www.oberon.ethz.ch/genealogy.html

    B> Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)! И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!


    Естественно что невозможно перенести на safe систему unsafe язык программирования. Никаких Си/Си++ под оберонами никогда не будет и ассемблеров тоже, по тойже причине.
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 09:34
    Оценка: +1
    Сергей Губанов пишет:

    > C>А если прибить _НУЖНО_? Например, если, модуль начал неограниченно

    > C>отжирать память.
    > Э-э-э..., модуль — не обладает "свободой воли" он не может что либо
    > делать. Вот, например, в модуле может быть определена процедура внутри
    > которой может быть код предназначенный для сжирания ресурсов. Так вот,
    > тот кто вызовет эту процедуру — вот он то и будет сжирать, а модуль
    > тут не причем.

    Уже прогресс. Но КТО вызывает данную функцию? Правильно, функция другого
    модуля, а ее вызвала функция еще одного модуля и т.д. По цепочке придем
    к корневому процессу. Ну и как система должна определить КАКОЙ модуль ей
    нужно прибить из-за превышения квоты?

    > C>Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках —

    > C>да, не бывает.
    > А чего же Вы тогда так волнуетесь по поводу этих самых недооперационок-то?

    Чтобы других не совращали...

    >>> Вместо них в объектно ориентированных операционных системах бывают

    >>> *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток,
    >>> а активный объект (*obj := NIL*).
    > C>Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_
    > ДВЕ
    > C>ЗАДАЧИ?
    > Каждый активный объект и есть задача. Как объекты создавать надо
    > показывать? Вот так: NEW(obj).

    NEW(obj) создает блок в памяти, который ничего не делает. Кто-то должен
    вызвать функцию, работающую с этим блоком. КТО?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 24.01.05 14:16
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Результаты 1 — 10 из примерно 29 400 для JavaOS.

    СГ>Результаты 1 — 10 из примерно 82 300 для Oberon OS.
    Можно еще посмотреть для
    Результаты 1 — 10 из примерно 14 300 000 для java os
    Результаты 1 — 10 из примерно 285 000 000 для windows
    Результаты 1 — 10 из примерно 222 000 000 для linux
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[7]: Как пишут драйверы на safe языках программирования.
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 08:46
    Оценка: :)
    Здравствуйте, Sergey, Вы писали:

    S>А есть средства, запрещающие использовать этот модуль простым смертным?

    S>Потому что с его помощью систему в капусту нашинковать ничуть не сложнее,
    S>чем с помощью С или ассемблера.

    Дело не в том что что-то сделать можно или нельзя, а втом, что работая на Си это можно сделать НЕЧАЯННО, а работая на safe языке это можно сделать только НАМЕРЕННО (намеренно используя модуль SYSTEM).


    Отсюда вывод — для того чтобы быть в полной безопасности:

    А) В Оберонах: никогда не пользуйтесь чужими непроверенными программами импортирующими модуль SYSTEM.

    Б) В Си/Си++/Assembler.... и т.д.: никогда не пользуйтесь вообще никакими чужими непроверенными программами.
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 25.01.05 08:50
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Значит если в самом языке нет средств для работы на низком уровне, то он не может на нем работать, так что ли? А вот, например, в языках Си/Си++ нет встроенной возможности для параллельной работы, и что из этого следует? А следует из этого то что используются внешние (по отношению к самому языку программирования) библиотеки.


    Объясни таки страждущим, в чем принципиальная разница между разрушением системы с помошью внешних библиотек, и разрушением системы с помощью встроенных средств языка.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 09:22
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>http://www.inr.ac.ru/~info21/motiv.htm

    СГ>

    СГ>Проект Оберон оказывает мощное влияние на мировую индустрию программирования: оно прослеживается в мега-проектах Java и .NET корпораций Sun и Microsoft (в Sun изучили коды Оберона еще в 1991 г., задолго до объявления Java, а по сущностным характеристикам языки Java и C# ближе к Оберону, чем к своим синтаксическим предшественникам). Это позволяет говорить о формировании под влиянием Оберона стандартной парадигмы программирования.

    А на генерики C#2 тоже оказал влияние оберон? (микрософты хотели сделать их еще в первом но не хватило времени)
    И на конструкции типа этой тоже оберон повлиял?
            static IEnumerable<int> FibonacciSeries()
            {
                int x1 = 1;
                int x2 = 1;
                while( true )
                {
                    yield return x1;
                    int x = x1 + x2;
                    x1 = x2;
                    x2 = x;
                }
            }
    ...
                    int i = 0;
                    foreach( int f in FibonacciSeries() )
                    {
                        Log.Write( "{0}", f );
                        if( ++i == 20 )
                            return;
                    }

    Надеюсь сам догадаешься что в лог напечаталось...
    Да и атрибуты тоже с оберона плагиатили...
    ...

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

    СГ>Разработка JIT-компилятора для языка Java по заказу компании Borland была выполнена компанией Oberon microsystems (помните BlackBox?)

    Интересно зачем багландам понадобился свой JIT для жабы?

    ЗЫ И вобще хватит заниматся всякой фигней типа какой язык из какого что позаимствовал... Все языки что-то заимствовали... Кроме пожалуй чисо концептуальных(на них писать не возможно) и типа BrainFack'а(эти языки еще хуже )
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 10:09
    Оценка: +1
    Здравствуйте, AVC, Вы писали:

    AVC>Работает же.

    Ну и мои серваки на С++ крутятся без сбоев...
    AVC>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.
    Мне было бы спокойнее если бы там использовали функциональные языки. Они всетки построже будут.
    AVC>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.
    Весьма "разумно" особенно учитывая что типизация в С++ сильнее чем в обероне... То что ее можно послать другой вопрос... в обероне (как мы выяснили
    Автор: AVC
    Дата: 24.01.05
    ) тоже можно...
    AVC>В принципе, Си++ — язык для детской песочницы.

    Такое себе даже фанаты C# не позволяют.
    AVC>Персоналки, "поставщик кода отвтетственности не несет" и т.п.
    А... Ну-ну...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[13]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 10:26
    Оценка: :)
    Здравствуйте, AndrewVK, Вы писали:

    AVC>>Уважаемый AVC.

    AVC>>Приятно.
    AVK>Спелись

    Не, ну приятно же: уважаемый!
    А остальные то все больше — скотиной...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 16:31
    Оценка: -1
    Здравствуйте, WolfHound, Вы писали:

    Остановлюсь только на одном моменте.

    AVC>>Особенно смешна идея зацепить граф объектов за глобальную переменную.

    AVC>>Т.е. об указателях в Обероне Вы не знаете ничего.
    WH>ГЦ он и в африке ГЦ и сыпится на хитрых графах которые цепляются за стек или статические переменные очень хорошо.

    Дело в том, что указатель в Обероне может указывать только на объект, расположенный в куче и не может указывать ни на стековую, ни на статическую переменную.
    Указатель получает свое значение только следующими путями:

    1) NEW(p) — создать новый объект;
    2) p := q; присвоить p значение другого валидного указателя q;
    3) p := NIL; указатель никуда больше не указывает.

    В начале указатель инициализирован NIL.
    Т.е. указатель либо указывает на объект в куче, либо равен NIL.
    И как же нам "зацепить" граф объектов за стек или статические переменные?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 20:10
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    AVC>>И как же нам "зацепить" граф объектов за стек или статические переменные?

    WH>ГЦ обыкновенный. Такойже как и везде. И валистся аналогично. А под словом зацепить за стек или статическую переменную я имел в виду что на стеке или в качастве статичекой переменной делаем указатель и присваиваем ему указатель на один из объектов графа объектов(которые ссылаются друг на друга)
    WH>А теперь забываем исделать
    AVC>>3) p := NIL; указатель никуда больше не указывает.
    WH>Все! Граф будет жить вечно. И такие ошибки уже были например в RSDN@Home(та софтина в которой я пишу этот пост) Да да утечки памяти в программе с ГЦ это реальность.

    Какой у Вас несчастный опыт борьбы с GC!
    Мне Вас искренне жаль!
    Но открою Вам один секрет.
    Я ведь тоже человек "дотошный".
    Задолго до этой нашей переписки я, с целью проверить Оберон (стоит ли тратить на него свои силы), многократно проделывал самые разные эксперименты.
    "Шалил".
    В том числе "забывал" присвоить NIL локальному указателю.
    Затем запускал GC и проверял состояние кучи.
    Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
    В отладчике смотрел, отводится ли повторно "потерянная" память.
    Так что Ваше убеждение в том, что "граф будет жить вечно" — ложно.
    По крайней мере, в отношении Оберона.
    Раз у Вас такие проблемы с GC, переходите на Оберон! Там их нет!

    WH>А про утечки внешних ресурсов я вобще молчу...


    И правильно! И про это Вам тоже лучше пока помолчать, пока не попробовали лично.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 25.01.05 23:11
    Оценка: :)
    Здравствуйте, AVC, Вы писали:


    AVC>Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока. Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.


    Гы-ы-ы, уже представляю себе топик: ObronOS vs QNX





    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 26.01.05 09:13
    Оценка: +1
    Здравствуйте, AVC, Вы писали:

    AVC>Какой у Вас несчастный опыт борьбы с GC!

    AVC>Мне Вас искренне жаль!
    А мне вас по скольку вы досихпор не поняли что ГЦ не панацея.
    AVC>Но открою Вам один секрет.
    AVC>Я ведь тоже человек "дотошный".
    AVC>Задолго до этой нашей переписки я, с целью проверить Оберон (стоит ли тратить на него свои силы), многократно проделывал самые разные эксперименты.
    AVC>"Шалил".
    AVC>В том числе "забывал" присвоить NIL локальному указателю.
    AVC>Затем запускал GC и проверял состояние кучи.
    AVC>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
    Значит плохо проверял.
    Пишу на C# думаю на оберон переведешь сам.(не компилил так что могут быть опечатки)
    Левый модуль(заметь никаких "опасных конструкций", ничего не импортирует и тем не мение... )
    public class BadClass
    {
        public BadClass(object o)
        {
            CollectTrash(o);
            CollectTrash(this);
        }
        public void BadMethod(object o)
        {
            CollectTrash(o);
        }
    
        public void ReleaseTrash()
        {
            collect_trash_here = null;
        }
    
        class List
        {
            public object trash;
            public List next;
        }
        static List collect_trash_here = null;
        void CollectTrash(object o)
        {
            List trash = new List();
            trash.trash = o;
            trash.next = collect_trash_here;
            collect_trash_here = trash;
        }
    }

    Надеюсь теперь до тебя дошло что я пытался сказать? Если посоздавать объекты класса BadClass педергать у них метод BadMethod и забыть дернуть ReleaseTrash то мусор будет жить вечно...

    Запомни ГЦ всеголишь алгоритм который завалить чуть сложнее чем банальный подсчет сылок. Но можно. Ибо ни один алгоритм не сможет предсказать все ошибки человека. Это не возможно.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 26.01.05 09:13
    Оценка: :)
    Здравствуйте, Дарней, Вы писали:

    Д>Вах-вах, как любопытно. То есть GC взял да и прибил объект, на который остались живые ссылки?

    +1
    Во-во...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 10:55
    Оценка: +1
    Сергей Губанов пишет:

    > WH> Надеюсь теперь до тебя дошло что я пытался сказать?

    > А при чем тут GC? Или Вы полагаете что его отсутствие вдруг волшебным
    > образом исправит допущенную Вами ошибку?

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 26.01.05 12:16
    Оценка: :)
    Здравствуйте, Сергей Губанов, Вы писали:

    Вы меня не слышите. Дальнейшие попытки чего либо объяснить предприниматся не будут. Ибо бесполезно.
    Прощайте.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 26.01.05 13:45
    Оценка: +1
    Здравствуйте, Дарней, Вы писали:

    Д>Я бы сказал немного по другому — в определенной (очень узкой) области такая замена приемлема.


    Я уже как то очерчивал эту область. Дело не в ресурсах. ОС без защиты памяти допустимы в том случае если мы контролируем весь софт, запускаемый под этой осью. Скажем для архитектуры PocketPC такая ось не годится, а для какого нибудь телефона вполне, хотя ресурсы и там и там сопоставимые.
    ... << RSDN@Home 1.1.4 beta 4 rev. 306>>
    AVK Blog
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 26.01.05 15:19
    Оценка: +1
    Hello, Сергей!
    You wrote on Wed, 26 Jan 2005 15:11:49 GMT:

    S>> В случае раздельных адресных пространств все просто — отстреливаем

    S>> дохлую задачу и освобождаем всю принадлежащую ей память. Что делать в
    S>> случае единого адресного пространства, когда вся надежда только на GC?

    СГ> Вот ума не приложу — какая разница сколько у Вас адресных

    СГ> пространств?
    Убей более не нужный объект — память освободиться сама
    СГ> (за счет того самого GC).

    Он не ненужный, он с ошибкой — взбесился и начал немерянно отжирать память.
    И другие объекты имеют указатели, показывающие на этот объект и его части.
    Что произойдет с ними, если убить дефектный объект?

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[52]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 07:51
    Оценка: :)
    Здравствуйте, Privalov, Вы писали:

    P>Здравствуйте, Трурль, Вы писали:


    Т>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?


    P>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?


    Неа, это волшебные оси
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 13:54
    Оценка: :)
    Здравствуйте, Денис Федин, Вы писали:

    ДФ>Здравствуйте, Шахтер, Вы писали:


    AVC>>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.


    Ш>>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.


    ДФ>С++ конечно НЕ язык для детской песочницы, но наиболее крупные и сложные проекты как писались так и пишуться на C (не С++), одним из оснований является тот факт, что компилятор ANSI C найдется на любой платформе, хоть на специфической ОС для марсохода.


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

    Вот по настоящему крупный и сложный проект — это когда есть новое голое железо, под которое надо написать все — и новую операционку, и новый компилятор нового языка (на самом себе), и прикладные программы. Именно в результате такой работы на свет появилась ОС Оберон и язык программирования Оберон. Именно поэтому они такие какие есть — все необходимое и достаточное в них есть, а лишних погремушек нет.
    Re[53]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 27.01.05 14:00
    Оценка: +1
    Здравствуйте, AVC, Вы писали:
    AVC>А чем в этом отношении Оберон хуже?
    Оберон хуже тем, что благодаря единому адресному пространству невозможно определить "владельца" ресурса. Поэтому невозможно, например, раздать квоты.
    AVC>В Обероне "плохой" процесс убивается, в Log выводится trap text.
    AVC>В данном пункте не вижу разницы.
    Разница в том, что в "обычной ОС" на этом этапе прибиваются все разделяемые ресурсы, захваченные убитым процессом. В Обероне в лучшем случае удастся отпустить ссылки, которыми владел убиваемый активный объект. Порожденные им объекты, доступные из других активных объектов, продолжат свое существование. Давайте рассмотрим абстрактный пример: наш активный объект создал окно. Конечно же, он передал ссылку на окно оконной подсистеме, чтобы та могла (к примеру) показать это окно в таскбаре. Случилось так, что АО должен умереть. Ок, теперь у нас осталась только одна ссылка на окно: та, что из оконной подсистемы. Упс, процесс умер, но окна его живут. А?
    AVC>А вопрос Трурль задал правильный.
    AVC>Противники Оберона постоянно высказываются в том духе, что "убийство процесса" есть главный (чуть ли не единственный) механизм безопасности в ОС.
    Нет. Главный механизм безопасности ОС — это изоляция песочниц друг от друга. Это позволяет время от времени делать уборку в песочнице, не трогая остальные. Идеальная ОС с единым адресным пространством в общем случае создает полносвязный граф. Рассуждения СГ об определении компоненты связности
    Автор: Сергей Губанов
    Дата: 27.01.05
    - детский лепет. В простейшем случае, убиваемый объект владеет ссылкой на System (MyComputer, Core — неважно что там еще). И эта "компонента связности" займет весь граф. Упс, добро пожаловть в BSOD.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[52]: А если подумать?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 14:23
    Оценка: :)
    Здравствуйте, Sergey, Вы писали:

    S>Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро

    S>прибиваем нафиг?

    А что, страшно, да?

    Подумаешь, перезапустим пару-тройку системных объектов...

    Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и кричите: "Этого не может быть потому что этого не может быть никогда!"





    Вспомните, чем отличается принцип построения той же самой Aos BlueBottle от традиционных Windows/UNIX. В традиционных Windows/UNIX поверх железа работает ядро операционки, поверх ядра работают рантайм системы для разных программ написанных на всяких языках программирования, в этих рантайм системах выполняются приложения.
    Железо ->- Ядро ->- Рантайм(ы) ->- Приложения

    Ядро пишется на Си или вообще на ассемблере. Приложения уже можно писать на ЯВУ.

    В Aos BlueBottle все наоборот, там поверх железа работает рантайм система языка программирования Active Oberon.
    Железо ->- Active Oberon runtime system ->- Модули операционки + модули приложений

    Операционка и ее приложения целиком пишутся на ЯВУ Active Oberon и исполняются в одной и тойже среде исполнения. Рантайм система не видит разницы между объектами операционки и объектами приложений. Модули самой ОС с точки зрения рантайм системы ни чем не отличаются от модулей приложений.
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 14:33
    Оценка: -1
    Здравствуйте, Sinclair, Вы писали:

    AVC>>А чем в этом отношении Оберон хуже?


    S>Оберон хуже тем, что благодаря единому адресному пространству невозможно определить "владельца" ресурса.


    С какой стати?
    Каким макаром вдруг адресные пространства связаны с владельцами ресурсов?


    S> В простейшем случае, убиваемый объект владеет ссылкой на System (MyComputer, Core — неважно что там еще).

    S> И эта "компонента связности" займет весь граф. Упс, добро пожаловть в BSOD.

    Вот именно, что это он обладает ссылкой на нее, а не она обладает ссылко на него. Он ей безразличен. Компонента связности в точности равна аналогичному понятию ПРОЦЕССА в Windows/UNIX. Как Windows/UNIX процессы не знают друг о друге, так же и тут, одна компонента связности графа объектов не знает о других.
    Re[59]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 16:07
    Оценка: :)
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Курилка, Вы писали:


    К>> Ага, а как же пример с десктопом — он знает об окне, но десктоп не удаляется...


    СГ>Значит сделано по умному.


    Вот и давайте будем поклоняться умному Вирту!
    Мы не знаем как оно работает, но ведь великая вещь!
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 27.01.05 16:15
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Не используйте. Язык это допускает (выделил жирным шрифтом):


    СГ>За исключением таких встроенных систем, где не используется динамическое управление памятью, или где ее можно разместить только однажды и никогда не нужно освобождать, требуется автоматический сбор мусора.


    Мимо кассы. Если не используется динамическое управление памятью, то ГЦ просто не нужен. А если используется, то без него никак
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 12:18
    Оценка: +1
    Трурль пишет:

    > C>Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в

    > C>2 раза по памяти, по сравнению с non-realtime GC).
    > Возможен с бааальшим оверхедом, а возможен и с небольшим. В XO/2
    > выбрали второе.

    Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x
    оверхедом. Синхронный — возможен и с меньшим, но и там сложно дать
    жесткие временные гарантии — проблемы появляются в случаях, когда GC
    нужно прерывать во время его работы.

    Вообще, GC для realtime не стоит использовать — не нужен он там.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 28.01.05 13:14
    Оценка: :)
    Здравствуйте, prVovik, Вы писали:

    V>Представляю себе сообщение информационного агентва:

    V>

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


    Другой вариант гораздо более вероятен.

    Как выяснила коммиссия, взрыв на такой-то АЭС произошел из-за нелепой случайности. Операционная система "убила" процесс, управляющий одним из критических блоков АЭС. Произошла ошибка Access Violation. Все ПО было написано на Си++.
    По предварителным оценкам, жертв...
    Страуструп и Торвальдс объявлены Интерполом в розыск.


    V>Короче, ГЦ и СРВ — это вещи несовместимые.


    На практике я не использую ГЦ в СРВ.
    Так же как и free, delete и т.п.
    В таких случаях "свободные" указатели не возвращаются в кучу, а "складируются" в стеках (например).

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 28.01.05 13:55
    Оценка: +1
    Здравствуйте, Sergey, Вы писали:

    S>В том числе, что при выгрузке модулей без специальных мер не могут

    S>образоваться дохлые указатели?
    "Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не образуются на что попало. Т.к. во-превых: указатель на объект другого модуля — это не просто указатель, во-вторых: всё остальное является копиями. Главное, что дохлый указатель — это правильный указатель, т.е. null или ссылка на InvalidObject, а не мусор.

    A>> Так что я согласен с Сергеем (если, конечно, мне не докажут, что это

    A>> неправильная точка зрения). Кстати, в приведенном мной примере
    A>> единственная разница между модулями ядра и прикладными модулями
    A>> состоит в том, что модули ядра загружаются однократно и не выгружаются.
    A>> Т.е. это различие касается только динамического загрузчика. Во всем
    A>> же остальном
    модули ядра и прикладные модули для рантайма
    A>> равноценны.

    S>Ну а я считаю, что одними перечисленными мерами не обойтись, понадобится еще

    S>кое-чего. Как минимум — специальные средства межмодульного взаимодействия.
    Би зус лов на. Так же как недостаточно одного лишь GDTR.

    S>И что, она может быть больше 4Gb?

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

    S>Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули

    S>выгружаем, но объекты из них остаются ?
    Как я понимаю модуль — это единица кода. Данные тут ваще не при чём. Вы до сих пор не воткнули , что модуль — это не аналог процесса. Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

    A>> Просто системные дескрипторы "финализируются" (в случае необходимости)

    A>> соответствующими процедурами ядра.
    S>Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...
    А то.

    S>>> В принципе, я могу представить GC, который висящих указателей даже в

    S>>> такой ситуации не допустит и, скажем, их обнулит. Но это опять-таки
    S>>> перекладывание проблемы на программиста — он то может и не ожидать, что
    S>>> у него объекты, ссылки на которые он держит, пропадать начнут и вместо
    S>>> вызова их методов полетят исключения.

    A>> См. выше.

    S>А то, что выше — это тоже перекладывание проблемы на программиста. Он,
    S>кстати, может и не догадаться, что в данном конкретном случае дескриптор
    S>нужен.
    Обычно C++ гуру называют таких программистов безнадежными, жертва аборта, ошибка ДНК. Так что можно расслабиться.
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 16:04
    Оценка: -1
    Здравствуйте, Cyberax, Вы писали:

    C>Трурль пишет:


    >> C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.

    >> А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который
    >> возможен минимум с 2x
    >> оверхедом".

    C>Запускающийся независимо от желаний приложения, и работающий сколько ему

    C>захочется...

    C>Синхронный GC запускается явно по требованию.



    Вопрос.
    Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

    Ведь, по идее, если мы не вызываем NEW(p), то зачем GC напрягаться-то(???), он может спокойно курить... а вот как только мы вызвали NEW(p), так он сразу — если есть память, то мгновенно ее возвращает, а если нет, то тут он напрягается, трудится-работает убирает мусор, как только уберет сколько затребовали, возвращает ее и дальше курит...
    Re[56]: Один из способов решения
    От: Pazak Россия  
    Дата: 29.01.05 00:46
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Системный список указателей на пользовательские объекты можно написать так, чтобы он автоматически забывал о плохом объекте, псевдокод:


    Можно. А можно и не написать. Разговор-то идет о средствах, обеспечивающих безопасность системы автоматически, вне зависимости от криворукости программиста. А в том, что теоретически можно написать идеальную программу я, конечно, не сомневаюсь. Вот только практика и теория — обычно разные вещи...
    Ку...
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 13:19
    Оценка: :)
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> А что, стандарт Си++ и такие конструкции запрещает?

    >>
    >> union {
    >>   void *p;
    >>   void (*fp)();
    >> };
    >>

    ПК>Конструкцию — нет. А (предполагаемое) использование, заключающееся в записи в p с последующим чтением из fp (или наоборот) — да. Правда, контролировать компилятору/среде исполнения не предписывает, просто снимает с себя ответственность за последствия дальнейшей работы соответствующей программы.

    Я так и предположил: чтобы "списать" все беды на программиста.
    Вообще, интересное поведение компилятора: он не контролирует запрещенную конструкцию.
    Так что, когда говорят о "сильно типизированном Си++", мне почему-то вспоминается "перл" одного футбольного комментатора:

    Несмотря на хорошую погоду, многие болельщики предпочли переждать дождь дома.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 08.02.05 13:51
    Оценка: +1
    AVC пишет:

    > Я так и предположил: чтобы "списать" все беды на программиста.

    > Вообще, интересное поведение компилятора: он *не контролирует
    > запрещенную конструкцию*.

    Еще раз: эта конструкция *НЕ* запрещена, она полностью семантически и
    синтаксически правильна, и может быть использована во вполне нормальных
    целях. Union'ы _явно_ были введены в Стандарт именно для специальных
    трюков с битами.

    Кстати, лично я не представляю, как такую конструкцию можно написать
    случайно. Ну а то что С и С++ дают достаточно средств, чтобы эффективно
    выстрелить себе в ногу — давно известно.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 08.02.05 14:36
    Оценка: +1
    AVC,

    > Вообще, интересное поведение компилятора: он не контролирует запрещенную конструкцию.


    Конструкция не запрещена. У нее есть вполне законные варианты использования. Запрещено подмножество сценариев использования, включающих запись в один член, а чтение из другого. Компилятор эти варианты в общем случае отследить не может. Систему исполнения этим нагружать стандарт не требует, но и не запрещает: исключение в результате неверного использования — одно из возможных последствий, если так решат разработчики конкретного компилятора.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 16:39
    Оценка: -1
    Здравствуйте, Кодт, Вы писали:

    К>В Quick/Visual Basic тоже

    К>Кстати, а это именно прямоугольник, или массив с рваным краем (jagged array) ?

    Это именно прямоугольник.

    К>Кстати. То, что в С++ это делается не на уровне языка, а с помощью библиотек (в Фортране, кстати, тоже; без библиотек Фортран был бы нищ, как полковник Кудасов), — содержит большое достоинство.


    То, что в Си++ это можно делать не на уровне языка — достоинство.
    Но не новое, и свойственное многим языкам.
    Разница только в том, что Си++ перегружает оператор индексации. Т.е. можно использовать квадратные скобки, а в других языках используются круглые. Мне кажется, что это не принципиально.
    А вот то, что в Си++ это не сделано на уровне языка — явный недостаток.
    Не городить же всякий раз огород из-за ерунды.

    К>А если какое-то представление оказалось зашито в язык, то оно ставит остальные в неравные условия перед разработчиком алгоритмов.


    Просто доведите это свое утверждение до логического конца.
    Вы придете к языку ассемблера.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[53]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 10.02.05 09:03
    Оценка: +1
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Да как же? Не вижу я чего-то массива массивов.


    СГ>Ваш square[X][Y] — это двумерный массив.

    СГ>Ваш *jagged[X] — это массив указателей.

    СГ>В то время как массив массивов вот какой: ARRAY OF ARRAY OF Element.


    Ещё раз для тех, кто в Обероне: указатель на массив и указатель на одиночный элемент в С/С++ неразличимы.

    СГ>"ARRAY OF", и "ARRAY N OF" — это базовые типы. Комбинируя их в сочетании с другим базовым типом "POINTER TO" можем получить очень много разных комбинаций (почувствуйте разницу):


    Библиотека STL — тоже базовая. Можешь поэкспериментировать с разнообразными комбинациями векторов и обычных массивов.
    typedef int five_ints[5];
    five_ints a[3]; // массив 3*5
    five_ints b[] = { {0}, {0}, {0}, {0} }; // 4*5
    vector<five_ints> c(n); // n*5, где n - переменная

    ну и указатели туда же, и т.д. и т.п.

    СГ>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.


    Беспочвенный шовинизм.
    Перекуём баги на фичи!
    Re[6]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 09:22
    Оценка: -1
    Здравствуйте, Cyberax, Вы писали:

    C>Например, в MFC можно сделать "активный объекты", наследуя их от

    C>CAppThread

    Разумется нельзя! Активные объекты подразумевают особый планировщик параллельного исполнения активностей. В то время как планировщик процессов/потоков работает совершенно по другому принципу.


    Прежде чем реализовывать активный объект, обратите внимание на самый обыкновенный пассивный объект:
    MODULE BoundedBuffers;
      TYPE
        Item* = OBJECT; (* generic object *)
    
        Buffer* = OBJECT
          VAR h, n: INTEGER; 
          B: ARRAY * OF Item;
    
        PROCEDURE Get*(): Item;
          VAR x: Item;
        BEGIN {EXCLUSIVE}
          AWAIT(n # 0); (* buffer not empty *)
          x := B[h]; h := (h+1) MOD LEN(B); DEC(n);
          RETURN x
        END Get;
    
        PROCEDURE Put*(x: Item);
        BEGIN {EXCLUSIVE}
          AWAIT(n # LEN(B)); (* buffer not full *)
          B[(h+n) MOD LEN(B)] := x; INC(n)
        END Put;
    
        PROCEDURE &Init(max: INTEGER);
        BEGIN (* initializer *)
          NEW(B, max); h := 0; n := 0
        END Init;
    
      END Buffer;
    
    END BoundedBuffers.

    Как Вы в MFC реализуете AWAIT? А никак, разьве только бесконечным циклом который будет есть процессорное время постоянно проверяя условие истинности!!! Кстати, не забудьте, что EXCLUSIVE — это метка блока исполняющегося целиком, как одна элементарная (атомарная) инструкция. И внутри этой атомарной элементарной инструкции Вы должны будете запустить бесконечный цикл проверки условия AWAT(condition)...




    Подсказка.
    В рантайм системе Aos инструкция AWAIT просто ставит активность (активный объект) в очередь ожидания выполнения условия, так что лишнее процессорное время не расходуется. Активных объектов одновременно может быть десятки тысяч! Представьте что будет (в случае MFC), кода 50'000 потоков будут каждый в своем бесконечном цикле AWAIT дожидаться чего-нибудь. Вроде ничего не происходит, все просто чего-то ждут, а процессор загружен на 100%.
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 13:06
    Оценка: +1
    Сергей Губанов пишет:

    > Подсказка.

    > В рантайм системе Aos инструкция AWAIT просто ставит активность
    > (активный объект) в очередь ожидания выполнения условия, так что
    > лишнее процессорное время не расходуется. Активных объектов
    > одновременно может быть десятки тысяч! Представьте что будет (в случае
    > MFC), кода 50'000 потоков будут каждый в своем бесконечном цикле AWAIT
    > дожидаться чего-нибудь. Вроде ничего не происходит, все просто чего-то
    > ждут, а процессор загружен на 100%.

    RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных
    ОС. Еще рекомендую почитать про O(1) планировщики.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 10.02.05 14:01
    Оценка: +1
    AVC,

    > Т.к. в Си++ нельзя написать
    void foo(float a[][]);

    > то массива массивов (по крайней мере, в этом смысле) в Си++ нет.

    Даже если бы было можно, то означало бы это то же самое, что и
    void foo(float** a);

    В общем, к гадалке не ходи: есть встроенные массивы массивов в C++, нет встроенных массивов массивов в C++ — науке не известно Даже если принять точку зрения, что встроенные массивы массивов в C++ есть, то надо будет сразу делать кучу оговорок, что массивы в языках C и C++ вообще на положении бедных родственников (not a first class citizens). Что мне лично при использовании данных языков не нравится, но вероятность исправления данной ситуации, пожалуй, устремлена к 0 из-за соображений обратной совместимости.

    С другой стороны, имхо, верным будет и утверждение, что в C++ это компенсируется развитыми возможностями создания своих типов, по использованию, фактически, не отличающихся от встроенных.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 15:07
    Оценка: :)
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> Т.к. в Си++ нельзя написать
    void foo(float a[][]);

    >> то массива массивов (по крайней мере, в этом смысле) в Си++ нет.
    ПК>Даже если бы было можно, то означало бы это то же самое, что и
    void foo(float** a);


    Так то оно так.
    Но здесь опять есть свои странности и особенности ("фичи"). (Как и обычно в Си/Си++.)
    Например, следующий код
    #include <stdio.h>
    
    void foo(float a[][])
    {
    }
    
    int main()
    {
        return 0;
    }

    спокойно принимается компилятором Си (gcc), но не компилятором Си++ (g++).
    Компилятор же Microsoft не принял этот текст ни как "сишный", ни как "си++ный".
    Загадочна совместимость что между языками Си и Си++, что между компиляторами...

    ПК>В общем, к гадалке не ходи: есть встроенные массивы массивов в C++, нет встроенных массивов массивов в C++ — науке не известно Даже если принять точку зрения, что встроенные массивы массивов в C++ есть, то надо будет сразу делать кучу оговорок, что массивы в языках C и C++ вообще на положении бедных родственников (not a first class citizens). Что мне лично при использовании данных языков не нравится, но вероятность исправления данной ситуации, пожалуй, устремлена к 0 из-за соображений обратной совместимости.

    ПК>С другой стороны, имхо, верным будет и утверждение, что в C++ это компенсируется развитыми возможностями создания своих типов, по использованию, фактически, не отличающихся от встроенных.

    "И ты прав. И ты прав."

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 11:18
    Оценка: +1
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>С точки зрения embedded программирования для устройсвт с небольшой производительностью оберон плохо применим. Ему ран-тайм нужен в обязательном порядке (тлт можно без него? хотя сомнеаваюсь). А если на не нужны ни активный объекты, ни сборщики мусора (для большого количества встроенных приложения можно вообще статически данные выделять), то зачем платить памятью и производительностью за этот ран-тайм. А минимальной ядро для организации параллельных вычислений и синхронизации можно втиснуть в несколько сотен байт или пару килобайт


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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[14]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 11.02.05 13:05
    Оценка: +1
    Здравствуйте, RailRoadMan, Вы писали:

    RRM> А как создать объект на стеке?


    Очевидно, что Вы и AVC сейчас немного о разных Оберонах разговариваете.
    Вы говорите об объектах имея в виду OBJECT из Active Oberon, которые действительно есть reference type и на стеке их быть не может. В это же самое время, AVC говорит об объектах имея в виду RECORD из просто Modula, Oberon, Oberon-2, Component Pascal... — там объекты можно размещать как на стеке так и в куче.

    Еще AVC, очевидно, говоря о том что написать рантайм оберона можно на самом обероне не используя ассемблера имеет в виду псевдомодуль SYSTEM, который предоставляет такие возможности. Например для ETH Oberon псевдомодуль SYSTEM такой: http://www.oberon.ethz.ch/SYSTEM.html Таким образом для переноса оберона на другую платформу нужно будет перенести всего лишь этот один маленький псевдомодуль, а все остальное просто перекомпилировать с этим новым псевдомодулем.
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 14.02.05 04:39
    Оценка: :)
    Здравствуйте, AVC, Вы писали:

    AVC>Модула-2 используется в космической промышленности (кстати, в том числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.

    AVC>Оберон-2 используется, например, в NASA.

    Точные ссылки и данные — в студию! Хватит уже фраз в духе "говорят, в Москве кур доЯт".

    AVC>Беспилотные вертолеты по-прежнему летают. (Кстати, OLGA означает Oberon language goes airborne.)


    Да, летают. Вероятно, только благодаря Оберону.

    AVC>Хотя эта сфера развивается очень быстро, и я допускаю, что ПО, написанное лично Виртом, в новых образцах уже не используется.


    Может быть, и Оберон там давно уже не используется?

    AVC>Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.

    AVC>Вы можете найти их и в языках Java и C#, и в JVM и в .NET.

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

    AVC>Что касается учебной сферы, то по книгам, языкам и системам Вирта учатся во всем мире. (В частности, ETH Oberon System 3 изучается в ряде западных учебных программ.


    роль его работ для обучения я и не оспариваю

    AVC>Я уж не говорю о том, как изучали ее код в Sun в начале 90-х годов. Очень творчески. )


    Про С++ это часто говорят, да и сходство явно наблюдается. Про Смоллток — говорят. Про Оберон — нет.
    Тебе единственному про это рассказали, или ты сам в этом процессе участвовал?

    AVC>Хочу отметить (как личное), что именно в книгах Вирта я впервые встретил примеры построения целых программ от начала до конца, а не общие рассуждения в стиле Буча.


    Придет время — и до книг Буча ты тоже дорастешь.

    AVC>Так что небезполезную жизнь прожил Вирт, как бы Вам, видимо, не хотелось доказать обратное.


    Если мне этого захочется — я прямо так и скажу. Не надо заниматься измышлениями.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 14.02.05 12:14
    Оценка: +1
    Здравствуйте, AVC, Вы писали:

    AVC>А сколько, интересно, стоит такой переход?


    сравнимо со стоимостью полной разработки заново

    AVC>Кроме того, существует множество конверторов с языка на язык.


    это наверно тоже была шутка

    AVC>Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка?


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

    AVC>А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены.


    Который, конечно же, был абсолютно несовместим с Паскалем и не имел никакого распространения по сравнению с ним же. Иными словами — очередной "Неуловимый Джо" в мире программирования. Ну и зачем тогда его рассматривать?
    Если бы Вирт потратил хоть небольшую часть времени не на размножение бесконечных несовместимых вариаций и диалектов, а на заботу о совместимости и/или интеропе — глядишь, его творениями и пользовались бы сейчас. Когда говорят про его "непрактичность" и "оторванность от жизни" — говорят именно про это.
    Какими будут контр-аргументы?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 12:37
    Оценка: :)
    Здравствуйте, Дарней, Вы писали:

    AVC>>А сколько, интересно, стоит такой переход?

    Д>сравнимо со стоимостью полной разработки заново

    Может быть, в таком случае стоило остановиться на Фортране?

    AVC>>Кроме того, существует множество конверторов с языка на язык.

    Д>это наверно тоже была шутка

    Отнюдь. (Как ловко я ввернул это слово. )
    Например, та же фирма XDS часто предоставляет конверторы с языка на язык.
    В конце концов, это ведь всего лишь разновидность компиляции.

    AVC>>Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка?

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

    Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально.

    AVC>>А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены.

    Д>Который, конечно же, был абсолютно несовместим с Паскалем и не имел никакого распространения по сравнению с ним же. Иными словами — очередной "Неуловимый Джо" в мире программирования. Ну и зачем тогда его рассматривать?
    Д>Если бы Вирт потратил хоть небольшую часть времени не на размножение бесконечных несовместимых вариаций и диалектов, а на заботу о совместимости и/или интеропе — глядишь, его творениями и пользовались бы сейчас. Когда говорят про его "непрактичность" и "оторванность от жизни" — говорят именно про это.
    Д>Какими будут контр-аргументы?

    Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована.
    Но его языки были бы хуже.
    Например, были бы такими же как Си++.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 15.02.05 08:13
    Оценка: :)
    Здравствуйте, Cyberax, Вы писали:

    >> Может быть, в таком случае стоило остановиться на Фортране?


    C>Интересно, почему же большую часть научного софта до сих пор на нем

    C>пишут?

    Тот софт для суперкомпьютеров, в то время как для PC научный софт пишут на модификации языка Oberon-2 под названием Component Pascal (http://www.inr.ac.ru/~info21/).
    Re[19]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 15.02.05 09:19
    Оценка: +1
    Здравствуйте, RailRoadMan, Вы писали:

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


    Например, вместо модели "Итератор произвольного доступа" (частным случаем которого является указатель) мы используем модель "Диапазон с доступом по индексу".
    Выражаясь на С++,
    typedef unsigned long address_t; // предположим, что это такой встроенный тип
    
    template<class T>
    class range
    {
    public:
      range(address_t start, int count); // конструктор низкого уровня
    
      range(T& var); // диапазон доступа к одиночному объекту
      template<int C> range(T array[C]); // диапазон доступа к массиву
    
      int count() const;
      T& operator[](int index) const;
      range subrange(int offset, int count) const;
      range domain() const; // возвращает полный диапазон
    
    private:
      address_t start_; int total_; // полный диапазон
      int offset_, count_; // действующий диапазон
    };
    Перекуём баги на фичи!
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 16.02.05 13:14
    Оценка: +1
    Здравствуйте, Костя Ещенко, Вы писали:

    >> Вот ты для разнообразия и спроси математика, какими способами можно представить множества...

    >> Навскидку:
    >> — предикат как чёрный ящик
    >> — предикат как формула
    >> — булев вектор (элементы универсума пронумерованы)
    >> — упорядоченная последовательность (над элементами определено отношение порядка)
    >> — неупорядоченная последовательность (над элементами определено отношение эквивалентности)

    КЕ>- еще порождающая функция — yield'ещая все элементы множества или выставляющая наружу итератор по элементам


    Это уже реализация (в общем случае неупорядоченной) последовательности... Из неё можно тоже наветвить разновидностей. По классификации STL, например
    — разрушающее чтение (output iterator) — yield
    — последовательный доступ (forward и bidirectional)
    — произвольный доступ
    Перекуём баги на фичи!
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 16.02.05 17:01
    Оценка: :)
    AVC пишет:

    > СГ> Кстати про множества, а почему элементарный тип bool в языки

    > C++/Java/C# все-таки ввели, а элементарный тип "множество"
    > проигнорировали?
    > КЕ>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для
    > разных сценариев использования: std::bitset, boost::dynamic_bitset,
    > std::vector<bool>, std::set и до кучи std::multiset — множество с
    > повторениями.
    > Прослеживается очень интересный подход.
    > Когда надо проиллюстрировать величие Си++, он берется со всеми
    > библиотеками, даже нестандартными (пока?), как boost.
    > Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом"
    > виде.

    Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то
    С++-ники показывают еще более мощные аналогичные фичи _библиотек_.
    Причем при использовании этих библиотек внешний вид кода получается еще
    и получше обероновского.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 16.02.05 23:24
    Оценка: :)
    AVC,

    >>>
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());


    > ПК> Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?


    > Опаньки! неужели сам...


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

    > Павел, а где, собственно, ошибки?

    > Вот беру исходник
    >
    #include <list>
    >
    > using namespace std;
    >
    > list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
    >
    > int main()
    > {
    >     return 0;
    > }

    > и компилирую. Ошибок нет!

    Т.к. AVC, хитро заложивший мину, делает невинные глаза (*), то для тех, кто от C++ пострадал в недостаточной степени, позволю прокомментировать код, приведенный выше. В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

    Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):
    list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );




    (*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил
    Posted via RSDN NNTP Server 2.0 alpha
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 17.02.05 13:15
    Оценка: +1
    AVC пишет:

    > C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то

    > C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_.
    > И в чем разница? Почему "эээ, нет"?

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

    >list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

    >
    > А уж про сообщения об ошибках, которые "вываливают" большинство
    > Си++ных компиляторов я вообще молчу.

    Вполне нормальные сообщения. Правда длииииинные.

    > Хотя, на самом деле это показывает реальную меру "мощи" Си++.


    Это мера _практичности_ языка С++. При его разработке не старались
    добавить языковую поддержку как можно большего числа фич (типа
    множеств), а пытались дать достаточно средств, что можно было комфортно
    реализовать как максимальное число фич.

    А вот Вирт решил: "Так, нам нужен GC, множества и многомерные массивы
    непосредственно в языке. Остальное нам в языке не нужно.".

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 13:27
    Оценка: +1
    Здравствуйте, Cyberax, Вы писали:

    C>Сравни сложность изменения/замены бибилиотеки (ну захотелось мне другой

    C>способ представления матриц использовать) и сложность модификации языка.

    Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...
    Перекуём баги на фичи!
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 17.02.05 14:46
    Оценка: :)
    Здравствуйте, Костя Ещенко, Вы писали:

    КЕ>Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит № четыре миллиарда?


    Нет, не будет. Хотя сам язык этого не запрещает. Все дело в реализации.

    Реализация BlackBox 1.5 дает следующее:

    MIN(SET) = 0
    MAX(SET) = 31

    (MIN, MAX — стандартные процедуры-функции)
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 17.02.05 16:27
    Оценка: +1
    AVC пишет:

    > ПК>Тпру Касте Оберонопочитателей напоминаю, что я ни против Оберона,

    > ни против адептов ничего не имею ("Огонь, мы с тобой одной крови, ты и
    > я" ), так что иронию можно перенацелить на кого-нибудь более враждебно
    > настроенного. В данном случае мне было, действительно, интересно, как
    > же будет выглядеть код на Обероне. Про ошибки упомянул, чтобы не
    > написали объявление функции, а не чтобы задеть
    > Ну, виноват, прости мерзавца...
    > Вообще-то капкан на Cyberaxа ставил. Немного утомило вранье о сплошь
    > белом и пушистом (пардон, "шелковистом") Си++ном коде, приятном на
    > глаз и на ощупь.

    Да я понял. Я вроде бы никогда не утверждал, что С++ — это простой язык
    Но фичастый — это точно.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 16:48
    Оценка: :)
    Здравствуйте, Кодт, Вы писали:

    К>Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём библиотеки, эквивалентный STL?


    Вот-вот, все они тут хотят моей смерти.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 20.01.05 05:50
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Имеет значение. Да еще какое!

    AVC>Просто Вы лично не пишете операционных систем.
    AVC>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety). Вы серьезно хотите сказать, что это не упрощает дизайн системы и не повышает ее надежность?

    Что, в Оберон-системах приложение может свободно менять содержимое памяти, принадлежащей другому приложению? Или это однозадачная система?

    P>>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.


    AVC>Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали.

    AVC>Когда это OS/360 на 80286 работала? :wow:

    Возможно, я где-то некорректно выразился. Может быть, правильнее будет так.

    В операционной системе OS/360 защита памяти не давала возможность пользовательскому приложению нарушить работоспособность системы, если оно некорректно написано. Приложение вылетало либо из-за неправильной адресации, либо из-за невозможности выделить память (GETMAIN), либо по тайм-ауту в случае зацикливания. При этом работа всей системы никак не нарушалась. И это работало задолго до появления защищенного режима.
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 20.01.05 10:14
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>В Оберонах нет такого понятия как память (то бишь адресного пространства как такового), хотя указатели есть.


    Указатели должны на что-то указывать. Стало быть, так или иначе, они хранят адрес указываемого объекта. Возможно, он недоступен пользователю, однако это вовсе не значит, что он не существует.

    СГ>Таким образом, вопрос "...менять содержимое памяти, принадлежащей другому приложению" не имеет физического смысла, поскольку в языке нет способа узнать что-либо про память, нельзя получить численное значение указателя (указатель — вещь в себе, его численное значение, если бы его можно было бы получить, оказалось бы вовсе не константой, а то и дело изменялось бы благодаря стараниям сборщика мусора).


    А это давно решается с помощью механизма трансляции адресов. По-моему, только в MS DOS реальный и виртуальный адреса всегда совпадают. Но MS DOS — примитивная однозадачная система. В нормальных многозадачных ОС пользовательская программа ничего не знает ни о реальных адресах, ни о других программах, выполняющихся параллельно.

    СГ>А раз так, то необходимость в создании множества виртуальных адресных пространств (для безопасности) больше не существует — достаточно одного единого на всю систему адресного пространства, а безопасность гарантируется языком программирования, рантайм проверками индексов массивов, контролем приведения типов.


    Выходит, что все приложения выполняются в едином адресном пространстве? Так мы это уже проходили. Windows 3.1 — первое, что приходит в голову.
    А если немного поднапрячься, то можно вспомнить персональную ЭВМ "Искра-226" с ее ОС, погруженной в Бейсик-интерпретатор. Она, правда, однозадачная. Гораздо примитивнее MS DOS. Но она грузилась в адресное пространство, недоступное пользовательским программам. И это при том, что в том древнейшем диалекте Бейсика вообще не было указателей и динамического управления памятью. Вот не думаю, что разработчики этой машины (я имею в виду оригинал, "Искра" была с чего-то французского передрана) были глупее нас с вами, предусмотрев подобную "защиту от дурака".

    Хотя после "Искры" PC раем земным казался. Это при том, что в нем что угодно можно было с памятью делать.
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 20.01.05 12:25
    Оценка:
    Sergey,

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


    Потому что на практике системы с разделяемыми адресными пространствами используют общие модули (ядро, драйверы и т.п.) с неизбежным наличием теоретической возможности порчи памяти/whatever...
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 20.01.05 15:42
    Оценка:
    Hello, Cyberax!
    You wrote on Thu, 20 Jan 2005 15:13:13 GMT:

    C> Ах... Как все просто в теории. А теперь к суровой реальности:

    C> Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
    C> бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
    C> ЧТО ставить квоты, явных процессов ведь нет?

    На модули, наверное. Винде, кстати, если выжрать всю память, тоже фигово
    будет.

    C> Точно так же — нужно обеспечить учет дефецитных ресурсов (сетевых

    C> соединений, открытых файлов и т.п.),

    С чего бы вдруг сетевым соединениям и открытых файлам быть дефицитными
    ресурсами?

    C> изоляцию приложений, работающих с разными привиллегиями,


    Прям щас пишу поддержку привелегий на уровне объектов для RPC. На С++.
    Сложности конечно есть, но непринципиальные.

    C> механизмы обхода защиты и т.п.

    Нафига нужны механизмы обхода защиты?

    C> В итоге получится тоже самое, что и в

    C> Юниксе/Винде.

    Да ну. Как напишешь, так получится. Может и QNX получиться, может и BeOS

    PS: я не защитник оберона, но, блин, аргументы-то и по толковей найти
    можно...

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 21.01.05 08:07
    Оценка:
    Hello, Cyberax!
    You wrote on Thu, 20 Jan 2005 17:52:53 GMT:

    C> В винде и юниксах я могу не дать приложению выжрать всю память. А в

    C> Обероне, видимо, нужно будет ставить квоты на System.Writeln

    Каким образом можно не дать приложению выжрать всю память в винде, если не
    секрет?

    C>>> Точно так же — нужно обеспечить учет дефецитных ресурсов (сетевых

    C>>> соединений, открытых файлов и т.п.),
    ??>> С чего бы вдруг сетевым соединениям и открытых файлам быть дефицитными
    ??>> ресурсами?

    C> А с того, что их количество ограничено.

    Чем ограничено? Имеющейся памятью?

    C> Еще примеры: открытые соединения к БД, курсоры в БД, графические

    C> описатели...
    Ну не стоит экстраполировать свойства ОС, с которым ты знаком, на ОС новые.
    Я, например, не вижу ни одной причины, по которым количество "графических
    описателей" (кстати, что это такое и обязательно ли их присутствие в
    оберонистой ОС?) должно быть ограничено чем-либо, кроме памяти.

    C> Ага, принципиальных сложностей нигде нет. А вот реализовать толковый

    C> механизм разделения привилегий для ОС — ВЕСЬМА непросто.

    А никто и не обещает, что это просто. Но я вот в упор не вижу, почему замена
    концепции процесса на концепцию модуля должна как-то повлиять на сложность
    реализации системы безопасности.

    C>>> механизмы обхода защиты и т.п.

    ??>> Нафига нужны механизмы обхода защиты?

    C> Hint: su, sudo


    Это, насколько я понимаю, не обход, а просто делегирование части полномочий.

    C>>> В итоге получится тоже самое, что и в

    C>>> Юниксе/Винде.
    ??>> Да ну. Как напишешь, так получится. Может и QNX получиться, может и
    ??>> BeOS

    C> Но уж никак не ОС в 50Кб кода


    Ну в 50Кб кода я тоже не верю А вот дискета-другая — вполне реально.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 21.01.05 09:13
    Оценка:
    Hello, Cyberax!
    You wrote on Fri, 21 Jan 2005 08:42:18 GMT:

    C> Пишем скрипт, который смотрит, чтобы никто не зажирался — нарушителей

    C> прибиваем.

    Что мешает написать подобный скрипт для Оберона? Есть какие-то
    принципиальные отличия винды от оберона в данном вопросе?

    ??>>>> С чего бы вдруг сетевым соединениям и открытых файлам быть
    ??>> дефицитными
    ??>>>> ресурсами?
    C>>> А с того, что их количество ограничено.
    ??>> Чем ограничено? Имеющейся памятью?

    C> Ограничением архитектуры.


    Архитектуры чего? И каким именно ограничением?

    ??>> Я, например, не вижу ни одной причины, по которым количество
    ??>> "графических описателей" (кстати, что это такое и обязательно ли их
    ??>> присутствие в оберонистой ОС?) должно быть ограничено чем-либо, кроме
    ??>> памяти.

    C> А я вижу. Например, каждый графический объект будет отжирать один

    C> аппаратный описатель графического ускорителя.

    Это плохой, негодный дизайн. Не надо писать операционку подобным образом,
    только и всего.

    C>>> Ага, принципиальных сложностей нигде нет. А вот реализовать толковый

    C>>> механизм разделения привилегий для ОС — ВЕСЬМА непросто.
    ??>> А никто и не обещает, что это просто. Но я вот в упор не вижу, почему
    ??>> замена
    ??>> концепции процесса на концепцию модуля должна как-то повлиять на
    ??>> сложность
    ??>> реализации системы безопасности.

    C> Потому что модуль — еденица деления КОДА, а процесс — это совокупность

    C> ПОТОКОВ исполнения кода.

    И что с того? Как это влияет на безопасность?
    Есть модуль, загруженный Васей, у него права рута. Есть модуль, загруженный
    Клавой, у него права гостя.
    Есть процесс, запущенный Васей, у него права рута. Есть процесс, запущенный
    Клавой, у него права гостя.
    В чем разница?

    C>>>>> механизмы обхода защиты и т.п.

    ??>>>> Нафига нужны механизмы обхода защиты?
    C>>> Hint: su, sudo
    ??>> Это, насколько я понимаю, не обход, а просто делегирование части
    ??>> полномочий.

    C> Это способ обойти защиту для некоторых случаев.

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

    C>>> Но уж никак не ОС в 50Кб кода

    ??>> Ну в 50Кб кода я тоже не верю А вот дискета-другая — вполне реально.

    C> Ну так Линукс с несколькими утилитами вполне помещается на дискету.


    Ну и что? Выводы-то какие?

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: BlackBox Россия ---
    Дата: 21.01.05 09:23
    Оценка:
    Здравствуйте, AVC, Вы писали:

    P>>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.


    AVC>Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали.

    AVC>Когда это OS/360 на 80286 работала?

    Privalov и не говорил, что OS/360 работала на 80286 — не надо видеть того чего нет.
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 21.01.05 11:23
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>В Обероне нет "висячих" указателей и возможности нарушить систему безопасности типов (type safety).


    ОН вернулся... трепещите, несчастные грешники!!! :lol:
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 21.01.05 11:59
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:

    >> Четвертые (и их, кажется, большинство) не могут себе представить
    >> создание нового процесса без UNIX-овского примитива *fork()*. (При
    >> этом они спокойно пишут многопоточные приложения и вопросов у них не
    >> возникает.) В Модуле-2 и Обероне-2 каждый процесс безраздельно владеет
    >> своими локальными (стековыми) переменными, а для разделяемых
    >> переменных существуют мониторы и семафоры.
    C>Ах... Как все просто в теории. А теперь к суровой реальности:
    C>Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
    C>бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
    C>ЧТО ставить квоты, явных процессов ведь нет?

    Как это нет явных процессов?
    Или Вы опять об отдельных "адресных пространствах"?
    Процессы (=задачи и т.п.) в Обероне есть, также как они были в Модуле-2.
    Если происходит исключение, то процесс убивается, выдается соответствующий дамп.
    Это так даже в ETH Oberon, не говоря уже о более развитых Оберон-системах.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 21.01.05 12:38
    Оценка:
    AVC пишет:

    > C>Ах... Как все просто в теории. А теперь к суровой реальности:

    > C>Как в Обероне борются с ресурсожорами? Начнет какой-нибудь поток
    > C>бесконечно жрать память — упадет ВСЯ система. Значит нужны квоты. Но на
    > C>ЧТО ставить квоты, явных процессов ведь нет?
    > Как это нет явных процессов?
    > Или Вы опять об отдельных "адресных пространствах"?
    > Процессы (=задачи и т.п.) в Обероне есть, также как они были в Модуле-2.
    > Если происходит исключение, то процесс убивается, выдается
    > соответствующий дамп.

    Ага. Представим, что содержащиеся в процессе объекты используются в
    другом процессе (у нас ведь одно адресное пространство), что с ними
    произойдет?

    Или что произойдет со статическими переменными? А как насчет открытых
    сетевых соединений?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 21.01.05 16:26
    Оценка:
    Sergey,

    > Есть модуль, загруженный Васей, у него права рута. Есть модуль, загруженный Клавой, у него права гостя.


    Насколько я понял, в Обероне каждый модуль может быть загружен только один раз. Соответственно, мне кажется, что будут проблемы из разряда того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту возможность у всех остальных пользователей...
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 21.01.05 20:53
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Или что произойдет со статическими переменными? А как насчет открытых

    C>сетевых соединений?
    Фигню какую-то говоришь. Разделяемая память — это разделяемая память. Экспорт объекта через границы модуля — отдельная серьезная задача (а не просто отдать 0x001e24fa).

    По поводу открытых файлов, соединений и пр — те же самые проблемы возникают и в обычной ОС. Вообще не нужно думать, что изоляция адресного пространства решает какие-то глобальные проблемы: по прежнему приходится отслеживать каждый "пук".
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 22.01.05 07:26
    Оценка:
    Poudy пишет:

    > C>Или что произойдет со статическими переменными? А как насчет открытых

    > C>сетевых соединений?
    > Фигню какую-то говоришь. Разделяемая память — это разделяемая память.
    > Экспорт объекта через границы модуля — отдельная серьезная задача (а
    > не просто отдать 0x001e24fa).

    То есть мне еще и нужно думать как "экспортировать" объекты между
    модулями, выполняющимися в одном треде? Если так, то В МОРГ.

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

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

    > По поводу открытых файлов, соединений и пр — те же самые проблемы

    > возникают и в обычной ОС.

    Где проблемы? При закрытии процесса прибиваются все открытые им handle'ы.

    > Вообще не нужно думать, что изоляция адресного пространства решает

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

    Чего отслеживать? В нормальных ОС если одна программа сделает GPF, то
    это не скажется на работе остальных.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 23.01.05 06:39
    Оценка:
    Здравствуйте, BlackBox, Вы писали:

    BB>Privalov и не говорил, что OS/360 работала на 80286 — не надо видеть того чего нет.


    Спасибо. Я действительно ничего подобного не говорил. :beer:

    А все остальное коллеги очень доступно уважаемому AVC объяснили, за что им тоже большое спасибо.
    Re: Нужна ли Оберон-ОС защита памяти?
    От: Borisman2 Киргизия  
    Дата: 23.01.05 07:42
    Оценка:
    AVC>Не подскажете, случайно, для каких языков потребовался защищенный режим, чтобы написанные на них программы друг друга не "убивали"?
    Правильный ответ — для языка ассемблера, точнее, для машинных кодов.

    Так как большинство языков транслируются в машкоды — то, соответственно и для всех языков.

    Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту. Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)!

    И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!

    За все надо платить.
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 23.01.05 09:06
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>То есть мне еще и нужно думать как "экспортировать" объекты между

    C>модулями, выполняющимися в одном треде? Если так, то В МОРГ.
    Пользовательскому приложению думать не нужно.
    Но операционке над этим приходится думать всегда. Процессор не делает в этом плане практически ничего. И разделяемую память, и маппинг файла в память, и OLE приходится настраиватиь или делать операционке.

    C>Да еще учитывая, что повсюду используются глобальные переменные...

    Они не глобальные в самом глобальном смысле. Это глобальные переменные в рамках модуля.

    C>Короче говоря: BlueBottle — игрушка, без защиты памяти, разделения

    C>процессов, без нормальной поддержки потоков, исключений,
    C>многопользовательской работы. В качестве учебного примера или для
    C>специальных целей — сойдет, но на что-то большее — не потянет.
    Ну конечно это не Win2003, (так же как и любая другая операционка )
    Ты как-то странно относишься к этим понятиям. BlueBottle имеет и защиту памяти и разделение (модулей) и потоки и исключения (свои ). Только делается это на софтварном уровне.
    Ты же в курсе про managed code. Всё там есть.

    >> По поводу открытых файлов, соединений и пр — те же самые проблемы

    >> возникают и в обычной ОС.
    C>Где проблемы? При закрытии процесса прибиваются все открытые им handle'ы.
    Ну я об этом и говорю: операционка за этим следит сама. Проц никакие сетевые подключения не мониторит. Я ваще не понимаю, к чему ты написал "А как насчет открытых
    сетевых соединений?"

    >> Вообще не нужно думать, что изоляция адресного пространства решает

    >> какие-то глобальные проблемы: по прежнему приходится отслеживать
    >> каждый "пук".
    C>Чего отслеживать? В нормальных ОС если одна программа сделает GPF, то
    C>это не скажется на работе остальных.
    Здесь тоже не скажется. GPF не портит данные. А OC и пользовательские программы всё равно работают палаллельно и независимо.

    C>--

    C>С уважением,
    C> Alex Besogonov (alexy@izh.com)
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 23.01.05 12:16
    Оценка:
    Poudy пишет:

    > C>То есть мне еще и нужно думать как "экспортировать" объекты между

    > C>модулями, выполняющимися в одном треде? Если так, то В МОРГ.
    > Пользовательскому приложению думать не нужно.
    > Но операционке над этим приходится думать всегда. Процессор не делает
    > в этом плане практически ничего. И разделяемую память, и маппинг файла
    > в память, и OLE приходится настраиватиь или делать операционке.

    Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть
    дерево процессов, каждый процесс независим от другого (если не
    используются специальные механизмы IPC). Если мы прибиваем один процесс
    или дерево — это не влияет на остальные процессы.

    А что будет у нас в Обероне, если прибить модуль System, например?

    > C>Да еще учитывая, что повсюду используются глобальные переменные...

    > Они не глобальные в самом глобальном смысле. Это глобальные переменные
    > в рамках модуля.

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

    > C>Короче говоря: BlueBottle — игрушка, без защиты памяти, разделения

    > C>процессов, без нормальной поддержки потоков, исключений,
    > C>многопользовательской работы. В качестве учебного примера или для
    > C>специальных целей — сойдет, но на что-то большее — не потянет.
    > Ну конечно это не Win2003, (так же как и любая другая операционка )
    > Ты как-то странно относишься к этим понятиям. BlueBottle имеет и
    > защиту памяти и разделение (модулей) и потоки и исключения (свои ).
    > Только делается это на софтварном уровне.
    > Ты же в курсе про managed code. Всё там есть.

    Несерьезно, так как в managed-код нельзя засунуть все, что нужно. А если
    все-таки это попробовать сделать — получится точно то же самое, что уже
    есть, только в managed-коде.

    >>> По поводу открытых файлов, соединений и пр — те же самые проблемы

    >>> возникают и в обычной ОС.
    > C>Где проблемы? При закрытии процесса прибиваются все открытые им
    > handle'ы.
    > Ну я об этом и говорю: операционка за этим следит сама. Проц никакие
    > сетевые подключения не мониторит. Я ваще не понимаю, к чему ты написал
    > "А как насчет открытых сетевых соединений?"

    Это означает, что Oberon-ОС должна следить за открытыми дефецитными
    ресурсами (а они *будут*), а для этого "плоская модель процессов" уже не
    подходит.

    > C>Чего отслеживать? В нормальных ОС если одна программа сделает GPF, то

    > C>это не скажется на работе остальных.
    > Здесь тоже не скажется. GPF не портит данные. А OC и пользовательские
    > программы всё равно работают палаллельно и независимо.

    GPF потом и не портит данные, что ОС предоставляет защиту. А кто помнит
    времена ДОСа — знает, что там одна прога могла легко запортить всю память.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[2]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 23.01.05 13:17
    Оценка:
    Здравствуйте, Borisman2, Вы писали:

    B>Если в Оберон-ОС предполагается, что для написания ВСЕХ программ поголовно используется Оберон-2, то можно несколько упростить защиту. Не дай Вам бог после этого написать что-то хитрое на встроенном ассемблере (который, насколько я помню, в Обероне есть)!

    B>И не дай бог потребуется в Оберон-ОС переносить компилятор языка с меньшей типозащищенностью, (того же С)!

    B>За все надо платить.


    Может быть сейчас с и в OberonOS так и есть. Но в принципе это не так. См. здесь
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 23.01.05 13:34
    Оценка:
    Здравствуйте, DJ KARIES, Вы писали:

    DK>Ибо нельзя испортить то, что не портится.

    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 23.01.05 13:43
    Оценка:
    Здравствуйте, Poudy, Вы писали:

    P>Ты же в курсе про managed code. Всё там есть.


    Есть. Но там путешествие через границу домена очень дорогое удовольствие.
    ... << RSDN@Home 1.1.4 beta 3 rev. 302>>
    AVK Blog
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 23.01.05 20:22
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    P>>Ты же в курсе про managed code. Всё там есть.

    AVK>Есть. Но там путешествие через границу домена очень дорогое удовольствие.
    Да, это так. Но во многом это благодаря ремотингу. Конечно, своя реализация взаимодействия через pipes будет экстремально быстрой. Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет.
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 23.01.05 21:15
    Оценка:
    Здравствуйте, Poudy, Вы писали:

    P>Да, это так. Но во многом это благодаря ремотингу.


    И что в нем не так?

    P>Конечно, своя реализация взаимодействия через pipes будет экстремально быстрой.


    В 2.0 есть IpcChannel.

    P> Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет.


    Ага, языком. А на практике GC работает в пределах домена и для передачи объекта хочешь-нехочешь, а сериализовать их придется. Ну или гонять unmanaged-куски памяти, но тогда ни о какой безопасности говорить не приходится.
    ... << RSDN@Home 1.1.4 beta 4 rev. 302>>
    AVK Blog
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 24.01.05 06:19
    Оценка:
    Здравствуйте, DJ KARIES, Вы писали:

    DK>Однозначно.

    DK>В настоящей Оберон-системе не было бы ни GDI+, ни DirectDraw7, ни Windows XP SP2.
    DK>Ибо нельзя испортить то, что не портится.

    Я понял!
    Оберон — он хороший. И Оберон-ОС — тоже хорошая.
    Это только программисты плохие. И железо плохое. Поэтому нужно новое железо, и новые программисты.
    И тогда будет все хорошо
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 08:20
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>А что будет у нас в Обероне, если прибить модуль System, например?


    Читать смешно.

    1) Модуль можно загрузить и можно выгрузить, а прибить нельзя. Если модуль А в данный момент времени используется модулями Б, В, и Г, то выгрузить его нельзя (предварительно, надо выгрузить модули Б, В, Г, и лишь затем А. Ведь они прилинкованы друг к другу).

    2) Ни потоков, ни процессов в объектно ориентированных операционных системах не бывает. Вместо них в объектно ориентированных операционных системах бывают АКТИВНЫЕ ОБЪЕКТЫ. То есть прибиванию подлежит не процесс и не поток, а активный объект (obj := NIL).

    3) Не фантазируйте — читайте доки http://bluebottle.ethz.ch/docu/index.html
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 08:35
    Оценка:
    Сергей Губанов пишет:

    > 1) Модуль можно загрузить и можно выгрузить, а прибить нельзя. Если

    > модуль А в данный момент времени используется модулями Б, В, и Г, то
    > выгрузить его нельзя (предварительно, надо выгрузить модули Б, В, Г, и
    > лишь затем А. Ведь они прилинкованы друг к другу).

    А если прибить _НУЖНО_? Например, если, модуль начал неограниченно
    отжирать память.

    > 2) Ни потоков, ни процессов в объектно ориентированных операционных

    > системах не бывает.

    Попрошу не обобщать, бывают и потоки, и процессы. В недооперационках —
    да, не бывает.

    > Вместо них в объектно ориентированных операционных системах бывают

    > *АКТИВНЫЕ ОБЪЕКТЫ*. То есть прибиванию подлежит не процесс и не поток,
    > а активный объект (*obj := NIL*).

    Еще раз _МЕДЛЕННО_: КАК ИСПОЛНЯЕТСЯ КОД? КАК ЗАПУСТИТЬ _ПАРАЛЛЕЛЬНО_ ДВЕ
    ЗАДАЧИ?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 24.01.05 08:35
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Здравствуйте, Poudy, Вы писали:

    P>>Да, это так. Но во многом это благодаря ремотингу.
    AVK>И что в нем не так?
    Синки.

    P>> Просто там не будет всех фич ремотинга с синками и прочим. Т.е. принципиально проблемы-то нет.

    AVK>Ага, языком. А на практике GC работает в пределах домена и для передачи объекта хочешь-нехочешь, а сериализовать их придется. Ну или гонять unmanaged-куски памяти, но тогда ни о какой безопасности говорить не приходится.
    Да, IMHO сеализовать ObjRef и аргументы вызовов просто необходимо. Это правильный подход. Другое дело, что используется общая медленная сериализация, что происходит обязательная проверка типа всех аргументов и т.д.
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 24.01.05 08:41
    Оценка:
    To Moderator: сорри за мат, больше такого не повторится .

    Здравствуйте, Cyberax, Вы писали:

    C>Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть

    C>дерево процессов, каждый процесс независим от другого (если не
    C>используются специальные механизмы IPC). Если мы прибиваем один процесс
    C>или дерево — это не влияет на остальные процессы.

    Давай разложим всё по полочкам.

    Идея №1 — изоляция процессов на уровне железа.
    В данном случае мы используем первое пришедшее в голову решение о том, что проги, работающие на виртуальной машине, не могут портить память других процессов. Чтобы это работало быстро, придется всё заимплементить в железе. В итоге мы имеем ОС, которая работает с железом напрямую, и пользовательские процессы, которые работают через уровень аппаратной абстракции. Тут есть тонкие архитектурные вопросы.
    1. Железо не стоит на месте, появляются всё новые и новые устройства. Это означает, что мы должны заклыдывать в железячную виртуальную машину только необходимый минимум — работа с памятью, с портами, вызовы, прерывания.

    2. Процессы должны общаться. Это необходимо реализовать в отдельном порядке. Самое простое — устроить на одной машине локальную сеть виртуальных машин. Думаю, именно поэтому в UNIX процессы так часто общаются по tcp.

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

    Минусы:
    — сложность такого проца мешает при построении хорошей масштабируемой архитектуры и её реализации.
    — большой расход памяти на обустройство виртуальной памяти.
    — потери производительности на переадресации.
    — постоянное переключение контекста снижает производительность; и чем дальше, тем сильней, т.к. размер контекста от проца к процу растет.
    — ошибки в самой ОС по-прежнему может завалить всю систему. а ОСь под такую архитектуру гипотетически более сложная.


    Идея №2 — изоляция процессов на уровне софта.
    Тут мы используем факт, что программа не запускается сама-собой. Её грузит загрузчик. Соответственно он может анализировать этот код и вставить в него запреты везде, где нужно. Разделение времени и прочее полностью должно разруливаться операционной системой.

    Плюсы:
    + Можно запрещать всё, что захочется, и управлять этим отдельными настройками.
    + Баги ловятся на уровне софта, а не на эмуляции железа, и это дешевле и проще.
    + Можно сделать более простой (и поэтому гипотетически более быстрый) проц, качество которого будет чуть меньше страдать от качества производства.

    Минусы:
    — Гипотетически всё это довольно сложный софт.
    — Программа в памяти занимает немного больше памяти, чем на диске.
    — ОСь и драйвера по-прежнему могут завалить систему.

    C>Да, и модуль может быть загружен только один раз. Так что они

    C>глобальные, просто с ограниченной зоной видимости.
    Нуу.. да, это недоделка, видимо. Это они не подумали .

    >> Ты же в курсе про managed code. Всё там есть.

    C>Несерьезно, так как в managed-код нельзя засунуть все, что нужно. А если
    C>все-таки это попробовать сделать — получится точно то же самое, что уже
    C>есть, только в managed-коде.
    На самом деле это неверно. Потому что managed code не означает, что это должен быть обязательно какой-то другой код, отличный от x86. Можно сделать загрузчик, который сделает из x86 managed code, т.е. везде вставит нужные проверки.

    C>Это означает, что Oberon-ОС должна следить за открытыми дефецитными

    C>ресурсами (а они *будут*), а для этого "плоская модель процессов" уже не
    C>подходит.
    Не понимаю, откуда такой вывод. ВСЕГДА существуют как минимум два "процесса" — ось и пользовательский.

    C>GPF потом и не портит данные, что ОС предоставляет защиту. А кто помнит

    C>времена ДОСа — знает, что там одна прога могла легко запортить всю память.
    В ДОС не было managed code.
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 24.01.05 08:44
    Оценка:
    Здравствуйте, Poudy, Вы писали:

    P>>>Да, это так. Но во многом это благодаря ремотингу.

    AVK>>И что в нем не так?
    P>Синки.

    И что синки? И которые кстати?
    ... << RSDN@Home 1.1.4 beta 3 rev. 299>>
    AVK Blog
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 24.01.05 09:18
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    P>>>>Да, это так. Но во многом это благодаря ремотингу.

    AVK>>>И что в нем не так?
    P>>Синки.
    AVK>И что синки? И которые кстати?
    Есть у меня мнение, что для работы IClientChannelSink & IServerChannelSink приходится упаковывать аргументы в IMessage. Т.е. я говорю не о реализации каких-нибудь там конкретных синков, снижающих производительность, а о самом механизме с передачей IMessage. Если редуцировать IMessage до байт без метаинформации, использовать более быструю специальную сериализацию, то должно ворочиться шустро.
    Re[3]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 09:30
    Оценка:
    Сергей Губанов пишет:

    > B> Не дай Вам бог после этого написать что-то хитрое на встроенном

    > ассемблере (который, насколько я помню, в Обероне есть)! И не дай бог
    > потребуется в Оберон-ОС переносить компилятор языка с меньшей
    > типозащищенностью, (того же С)!
    > Естественно что невозможно перенести на safe систему unsafe язык
    > программирования. Никаких Си/Си++ под оберонами никогда не будет и
    > ассемблеров тоже, по тойже причине.

    И по той же причине такая система никому нужна не будет.

    ЗЫ: поищи в гугде по слову JavaOS — будешь удивлен.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 10:15
    Оценка:
    Hello, Павел!
    You wrote on Fri, 21 Jan 2005 16:26:06 GMT:

    ??>> Есть модуль, загруженный Васей, у него права рута. Есть модуль,
    ??>> загруженный Клавой, у него права гостя.

    ПК> Насколько я понял, в Обероне каждый модуль может быть загружен только

    ПК> один раз. Соответственно, мне кажется, что будут проблемы из разряда
    ПК> того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту
    ПК> возможность у всех остальных пользователей...

    Если так, то придется изобретать контексты безопасности. В подобной системе
    это не должно быть слишком сложно. Хотя раз у них задачи все таки есть —
    задача должна хорошо подойти на роль контекста безопасности.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 13:54
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>...КАКОЙ модуль ей нужно прибить из-за превышения квоты?


    Модуль — это просто место в котором хранится код. Прибить модуль невозможно по определению.

    C>NEW(obj) создает блок в памяти, который ничего не делает.


    а если obj — активный объект, то делает. Активный объект живет своей жизнью (проявляет активность) параллельно с остальными активными объектами. Вот, например, в виндосе если взглянуть в Windows Task Manager в закладку Processes, то Вы увидите список работающих процессов, аналогично в Aos BlueBottle можно наблюдать список активных объектов.
    Re[4]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 14:05
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>И по той же причине такая система никому нужна не будет.


    Ну вот и договорились. На этом у Вас, надеюсь, все?

    C>ЗЫ: поищи в гугде по слову JavaOS — будешь удивлен.



    Посмотрел:

    Результаты 1 — 10 из примерно 29 400 для JavaOS.
    Результаты 1 — 10 из примерно 82 300 для Oberon OS.

    Чему удивиться?
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 14:09
    Оценка:
    Здравствуйте, BlackBox, Вы писали:

    BB>Здравствуйте, AVC, Вы писали:


    P>>>Кстати, это было известно задолго до появления защищенного режима (в Intel 80286), например, OS/360 ни разу не зависла из-за некорректно написанной пользоветельской программы.

    AVC>>Я что-то не понял. Своими интересными аргументами Вы меня в конец запутали.
    AVC>>Когда это OS/360 на 80286 работала?
    BB>Privalov и не говорил, что OS/360 работала на 80286 — не надо видеть того чего нет.

    Похоже, Вы правы, а я неправильно понял фразу.
    Беру назад свою реплику об "OS/360 на 80286".

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 14:19
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    BB>>Privalov и не говорил, что OS/360 работала на 80286 — не надо видеть того чего нет.

    P>Спасибо. Я действительно ничего подобного не говорил.

    Я неправильно истолковал Вашу фразу. В голове мелькнула дурацкая мысль: какая связь между 80286 и OS/360; может быть, имеется в виду "полуось"?
    Этой ошибочной ассоциацией и вызвана моя реплика.
    Беру ее назад.

    P>А все остальное коллеги очень доступно уважаемому AVC объяснили, за что им тоже большое спасибо.


    IMHO, "коллеги" пока что демонстрируют только свое непреклонное убеждение, что любая ОС должна быть клоном UNIX или Windows, везде и во все времена.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 24.01.05 14:31
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>IMHO, "коллеги" пока что демонстрируют только свое непреклонное убеждение, что любая ОС должна быть клоном UNIX или Windows, везде и во все времена.


    IMHO, OS/360 не похожа ни на Windows, ни на UNIX. Кстати, та же OS/2 тоже. И возможности защищенного режима она, AFAIR, использует лучше Windows. Не похожа она на клон. Речь шла о том, какой должна быть многозадачная ОС. О том, что нормальная ОС должна уметь защищать себя от криво написанных приложений.
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 14:51
    Оценка:
    Hello, AVC!
    You wrote on Mon, 24 Jan 2005 14:35:46 GMT:

    S>> Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF.

    S>> Требуется установить байт 0xE4000040 в 0xCE, шоб точку на экране
    S>> показать. Как это сделать, принимая во внимание, что "вопрос "...менять
    S>> содержимое памяти, принадлежащей другому приложению" не имеет
    S>> физического смысла, поскольку в языке нет способа узнать что-либо про
    S>> память, нельзя получить численное значение указателя (указатель — вещь
    S>> в себе, его численное значение, если бы его можно было бы получить,
    S>> оказалось бы вовсе не константой, а то и дело изменялось бы благодаря
    S>> стараниям сборщика мусора)."?

    A> Такой проблемы в Обероне нет, как и в Модуле не было.

    A> Неужели единственный способ обратиться к видеобуферу — это
    A>
     A> (* ((unsigned char *) 0xE4000000)) = 0xCE;
     A>

    A> Чем хуже, скажем,
    A>
     A> VideoBuffer.SetPoint(0, 0, 0xCE));
     A>

    A> или
    A>
     A> P[0][0] := 0xCE;
     A>

    A> где P — указатель на видеобуфер?

    Ты мне для начала покажи код, где ты присвоишь указателю на видеобуфер
    значение 0xE4000000 и объясни заодно, как это согласуется с высказыванием
    Губанова, которое я процитировал.
    А потом можно будет перейти к обсуждению строгой типизации и взаимодействия
    с внешним миром.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 15:00
    Оценка:
    Сергей Губанов пишет:

    > C>NEW(obj) создает блок в памяти, который ничего не делает.

    > а если obj — активный объект, то делает. Активный объект живет своей
    > жизнью (проявляет активность) параллельно с остальными активными
    > объектами. Вот, например, в виндосе если взглянуть в Windows Task
    > Manager в закладку Processes, то Вы увидите список работающих
    > процессов, аналогично в Aos BlueBottle можно наблюдать список активных
    > объектов.

    Прекрасно. Мы уже выяснили, что потоки называются в Обероне "активными
    объектами". Следующий вопрос: они образуют иерархию?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 15:02
    Оценка:
    Сергей Губанов пишет:

    > СГ>>Естественно что невозможно перенести на safe систему unsafe язык

    > программирования. Никаких Си/Си++ под оберонами никогда не будет и
    > ассемблеров тоже, по тойже причине.
    > Д>И драйверов к железу тоже никогда не будет?
    > Какая связь между языками Си/Си++ и драйверами?
    > Драйверы под оберон-системы пишутся на самих оберонах.

    А как суперзащищенный Оберон-драйвер будет работать с портами, IRQ и, не
    побоюсь этого слова, указателями?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 15:04
    Оценка:
    Сергей Губанов пишет:

    > C>И по той же причине такая система никому нужна не будет.

    > Ну вот и договорились. На этом у Вас, надеюсь, все?
    > C>ЗЫ: поищи в гугде по слову JavaOS — будешь удивлен.
    > Посмотрел:
    > Результаты 1 — 10 из примерно 29 400 для JavaOS.
    > Результаты 1 — 10 из примерно 82 300 для Oberon OS.
    > Чему удивиться?

    Извиняюсь, нужно заменить JavaOS на "Java OS". Получим 14800000 результатов.

    А вывод: есть мощные коммерческие Java OS'ы, которым BlueBottle и в
    подметки не годится, но все они крайне нераспространены.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 15:35
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Ты мне для начала покажи код, где ты присвоишь указателю на видеобуфер

    S>значение 0xE4000000 и объясни заодно, как это согласуется с высказыванием
    S>Губанова, которое я процитировал.
    S>А потом можно будет перейти к обсуждению строгой типизации и взаимодействия
    S>с внешним миром.

    Указатель на видеобуфер, скорее всего, устанавливается в пользовательском модуле, а в одном из модулей ядра. Ядро может быть написано как на Обероне, так и на ассемблере. Важно, чтобы модули расширения писались на Обероне. Поэтому вопрос, на самом деле, не слишком актуален.
    На всякий случай, напомню, что в Обероне, как и раньше в Модуле, существуют средства низкого уровня (low-level facilities), используемые для подобных целей.
    Они могут варьироваться от
    videobufferPtr := SYSTEM.VAL(VideobufferPtrType, E4000000H);

    в Обероне, до простого как мычание объявления
    videobuffer[E4000000H]: VideobufferType;

    как это было предложено делать в старой книге Вирта "Программирование на Модуле".

    А что такого страшного написал Губанов?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 15:39
    Оценка:
    Я хотел написать:

    AVC>Указатель на видеобуфер, скорее всего, устанавливается не в пользовательском модуле, а в одном из модулей ядра. Ядро может быть написано как на Обероне, так и на ассемблере. Важно, чтобы модули расширения писались на Обероне. Поэтому вопрос, на самом деле, не слишком актуален.


    "Не" куда-то пропало...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 15:54
    Оценка:
    Hello, AVC!
    You wrote on Mon, 24 Jan 2005 15:35:13 GMT:

    A> Указатель на видеобуфер, скорее всего, устанавливается в

    A> пользовательском модуле, а в одном из модулей ядра. Ядро может быть
    A> написано как на Обероне, так и на ассемблере.

    Нестыковка номер раз — утверждается, что ядро может быть написано только на
    обероне.

    A> самом деле, не слишком актуален. На всякий случай, напомню, что в

    A> Обероне, как и раньше в Модуле, существуют средства низкого уровня
    A> (low-level facilities), используемые для подобных целей.

    Нестыковка номер два — утверждалось, что низкоуровневых средств нет.

    A> А что такого страшного написал Губанов?


    Цитирую еще раз:
    1) "Драйверы под оберон-системы пишутся на самих оберонах"
    2) "...в языке нет способа узнать что-либо про память, нельзя получить
    численное
    значение указателя (указатель — вещь в себе, его численное значение, если бы
    его можно было бы получить, оказалось бы вовсе не константой, а то и дело
    изменялось бы благодаря стараниям сборщика мусора)"

    Соответственно, либо эти утверждения являются истиной, либо для
    Оберон-систем в принципе возможны драйвера
    Соответственно, если у нас низкоуровневый доступ, вопрос о защищенности
    переходит из качественного в количественный — скока там реально получится
    багов, роняющих систему. То, что такие баги будут в принципе возможны, уже
    очевидно.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 24.01.05 16:01
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Увы, я практически не знаком с устройством OS/360.

    Я тоже
    AVC>В принципе, я согласен с Вами в том, что "центр тяжести" обсуждения сместился к многозадачным ОС. Еще точнее, достаточно ли в многозадачной ОС загрузить каждый используемый модуль однократно, или требуется дублировать код по соображениям безопасности.
    Ну в винде код шарится между процессами. В Обероне шарится не только код но и данные что не есть гуд. Ведь основная проблема программ не АВ как здесь пытаются представить защитники оберона(у меня и в С++ никаких АВ нет), а ошибки в логике которые к АВ не приводят но они случаются гораздо чаще и проблем с ними гораздо больше особенно если это просчет в арихитектуре программы у которой исходники измеряются мегабайтами и это не по тому что программисты тупые, а по тому что меньше всеравно не получится.
    Я сейчас пишу под .НЕТ который защищен не хуже Оберона и прекрасно понимаю о чем говорю.
    AVC>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".
    1)Какие противники? Ты о чем? Чтобы у чегото были противники это что-то должно чегото стоить чего про обероны сказать нельзя. Народ тут просто развлекается...
    2)В том то и дело что могут себе представить что произойдет с системой без защиты в которой начинают запускать кучу разнородного софта. Защита от АВ это не защита. Данные и без АВ можно испортить.
    AVC>Должен признать, что и наши аргументы иногда неубедительны.
    Защита от АВ это конечно хорошо и с этим спорить глупо но назывть защиту от АВ панацеей еще глупее.
    AVC>Я думаю, все это по причине плохой информированности. Ведь по Windows, UNIX и Linux доступно море литературы, а вот книг по Оберону у нас в продаже нет.
    AVC>Это совсем не означает, что Windows или Linux — хорошо, а Оберон — плохо. Это всего лишь политика издательств.
    Судя по той информации которую предоставил гн Губанов и компания в оберонах есть только защита памяти, а этого не достаточно для стабильного функционирования системы. Да и если вспомнить про то что кое что всетки пишется на не безопасных языках, да и в Обероне
    Автор: AVC
    Дата: 24.01.05
    можно обратится куда не положено то и защита памяти не выглядит такой уж крутой...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 16:04
    Оценка:
    AVC пишет:

    > в Обероне, до простого как мычание объявления

    >
    >videobuffer[E4000000H]: VideobufferType;
    >
    > как это было предложено делать в старой книге Вирта "Программирование
    > на Модуле".

    Внимание, вопрос! А как GC будет взаимодействовать с такими указателями?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[6]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 24.01.05 16:21
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Hello, Сергей!

    S>You wrote on Mon, 24 Jan 2005 13:57:59 GMT:

    Д>>> И драйверов к железу тоже никогда не будет?


    СГ>> Какая связь между языками Си/Си++ и драйверами?

    СГ>> Драйверы под оберон-системы пишутся на самих оберонах.

    S>Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF. Требуется

    S>установить байт 0xE4000040 в 0xCE, шоб точку на экране показать. Как это
    S>сделать, принимая во внимание, что "вопрос "...менять содержимое памяти,
    S>принадлежащей другому приложению" не имеет физического смысла, поскольку в
    S>языке нет способа узнать что-либо про память, нельзя получить численное
    S>значение указателя (указатель — вещь в себе, его численное значение, если бы
    S>его можно было бы получить, оказалось бы вовсе не константой, а то и дело
    S>изменялось бы благодаря стараниям сборщика мусора)."?

    S>With best regards, Sergey.


    Скачайте сами и посмотрите. Система открытая. Лично я не смотрел, не знаю.
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 16:29
    Оценка:
    Hello, Сергей!
    You wrote on Mon, 24 Jan 2005 16:21:41 GMT:

    Д>>>> И драйверов к железу тоже никогда не будет?


    СГ>>> Какая связь между языками Си/Си++ и драйверами?

    СГ>>> Драйверы под оберон-системы пишутся на самих оберонах.

    S>> Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF.

    S>> Требуется установить байт 0xE4000040 в 0xCE, шоб точку на экране
    S>> показать. Как это сделать, принимая во внимание, что "вопрос "...менять
    S>> содержимое памяти, принадлежащей другому приложению" не имеет
    S>> физического смысла, поскольку в языке нет способа узнать что-либо про
    S>> память, нельзя получить численное значение указателя (указатель — вещь
    S>> в себе, его численное значение, если бы его можно было бы получить,
    S>> оказалось бы вовсе не константой, а то и дело изменялось бы благодаря
    S>> стараниям сборщика мусора)."?

    СГ> Скачайте сами и посмотрите. Система открытая. Лично я не смотрел, не

    СГ> знаю.

    Зачем? Я и так знаю, что без низкоуровневого доступа к памяти этого не
    сделать. Соответственно, либо в Обероне есть средства для такого доступа,
    либо драйвера/ядро написаны не на Обероне.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 16:31
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    A>> Указатель на видеобуфер, скорее всего, устанавливается в

    A>> пользовательском модуле, а в одном из модулей ядра. Ядро может быть
    A>> написано как на Обероне, так и на ассемблере.
    S>Нестыковка номер раз — утверждается, что ядро может быть написано только на
    S>обероне.

    Ага, понял. Устраивается, так сказать, очная ставка.
    Ядро может быть написано целиком на Обероне. Но на практике некоторая (небольшая) часть ядра часто пишется на ассемблере. Этот код мал, тщательно верифицирован и пишется в соответствии с требованиями Оберон-системы.
    Код же расширений системы пишется программистами на Обероне, чтобы позволить компилятору контролировать свойства кода.
    (В принципе, можно представить себе и создание "песочницы" для других языков: Си, Си++ и т.д. В таком случае они будут получать доступ к системе не прямо и эффективно, как программы на Обероне, а через специальный API, как, в принципе, это и делается в других системах. Так, как и привыкли делать программисты на этих языках.)

    A>> самом деле, не слишком актуален. На всякий случай, напомню, что в

    A>> Обероне, как и раньше в Модуле, существуют средства низкого уровня
    A>> (low-level facilities), используемые для подобных целей.
    S>Нестыковка номер два — утверждалось, что низкоуровневых средств нет.

    Средства низкого уровня упоминаются в описании языка Оберон.
    Некоторые из них являются частью псевдомодуля SYSTEM, например: BYTE, PTR, VAL и т.п.

    A>> А что такого страшного написал Губанов?

    S>Цитирую еще раз:
    S>1) "Драйверы под оберон-системы пишутся на самих оберонах"
    S>2) "...в языке нет способа узнать что-либо про память, нельзя получить
    S>численное
    S>значение указателя (указатель — вещь в себе, его численное значение, если бы
    S>его можно было бы получить, оказалось бы вовсе не константой, а то и дело
    S>изменялось бы благодаря стараниям сборщика мусора)"

    S>Соответственно, либо эти утверждения являются истиной, либо для

    S>Оберон-систем в принципе возможны драйвера
    S>Соответственно, если у нас низкоуровневый доступ, вопрос о защищенности
    S>переходит из качественного в количественный — скока там реально получится
    S>багов, роняющих систему. То, что такие баги будут в принципе возможны, уже
    S>очевидно.

    Низкоуровневый доступ может быть и запрещен при компиляции модулей, не входящих в ядро. Это зависит от предполагаемого использования Оберон-системы.
    Само выделение низкоуровневых средств языка в отдельную часть, которую можно и не разрешить на определенных уровнях системы, — хорошая мысль. Такое деление возникло еще в Модуле-2.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 16:51
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> в Обероне, до простого как мычание объявления

    >>
    >>videobuffer[E4000000H]: VideobufferType;
    >>
    >> как это было предложено делать в старой книге Вирта "Программирование
    >> на Модуле".
    C>Внимание, вопрос! А как GC будет взаимодействовать с такими указателями?

    С каким торжеством. Внимание! Вопрос!!!
    Да никак! Или Вы предполагаете, что сумасшедшие авторы ядра присвоят указателю на видеобуфер нулевое значение? Доступные же снаружи ядра расширения не могут задействовать GC для "удаления видеобуфера" — ведь у них только копии этого указателя.
    Кроме того, необязательно это должен быть указатель.
    Ведь я предлагал несколько решений. Указатель — только одно из таких решений. Просто Sergey хотел получить именно указатель.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 24.01.05 17:02
    Оценка:
    Hello, AVC!
    You wrote on Mon, 24 Jan 2005 16:51:50 GMT:

    A> них только копии этого указателя. Кроме того, необязательно это

    A> должен быть указатель. Ведь я предлагал несколько решений. Указатель -
    A> только одно из таких решений. Просто Sergey хотел получить именно
    A> указатель.

    Я имел в виду запись по адресу. Указатель это вообще термин конкретного
    языка (языков). Чтобы обрушить систему, нужна именно запись по произвольному
    адресу, не важно как конкретно она будет называться. Для этого вполне
    достаточен бейсиковский POKE.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 17:17
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    A>> Ага, понял. Устраивается, так сказать, очная ставка.

    S>Ну, примерно Просто в показаниях гражданина Губанова было замечено
    S>довольно много противоречий. Некоторые из них пора бы разрешить, иначе флейм
    S>совсем уж бессодержательный получается.

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

    A>> Ядро может быть написано целиком на Обероне.


    S>Ответ на этот вопрос зависит от того, есть ли в Обероне низкоуровневые

    S>средства. Для доступа к памяти и портам ввода/вывода хотя бы.
    S>Да, а типизация там статическая или динамическая?

    Средства низкого уровня в Обероне есть. Другое дело — кому они доступны. Это уже вопрос системной "политики".
    Типизация в Обероне — статическая.
    Но для указателей и параметров-переменных это требование смягчается, чтобы поддержать возможности ООП. Для них, кроме статического контроля базового типа, есть дополнительные средства:
    1) type test:
    IF (p IS NeededPtr) THEN ... END;

    2) type guard:
    p(NeededPtr).x := 21;

    или
    WITH p: NeededPtr DO ... ELSE (* если не хотим исключения *) END;



    S>Ну вот в это я уже верю. Для полного счастья не хватает обхода системы

    S>типов — чтобы можно было эффективно писать библиотеки ввода.

    Такие средства есть.
    Это уже упоминавшийся BYTEARRAY OF BYTE), кроме него: PUT, GET и т.д.
    Но это опять же средства низкого уровня.

    S>Есть идеи и получше — перенести проверки валидности указателей на уровень

    S>железа. Как Бабаян предлагает, например. Учитывая, что Intel купила МЦСТ,
    S>лично мне это представляется более вероятным, чем тотальное нашествие
    S>Оберон-систем.

    Интересно!
    Но мне приходится иметь дело с самыми разными процессорами, а не только Intel-овскими.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 17:18
    Оценка:
    AVC пишет:

    >>> как это было предложено делать в старой книге Вирта "Программирование

    >>> на Модуле".
    > C>Внимание, вопрос! А как GC будет взаимодействовать с такими указателями?
    > С каким торжеством. Внимание! Вопрос!!!
    > Да никак! Или Вы предполагаете, что сумасшедшие авторы ядра присвоят
    > указателю на видеобуфер нулевое значение? Доступные же снаружи ядра
    > расширения не могут задействовать GC для "удаления видеобуфера" — ведь
    > у них только *копии* этого указателя.

    GC при сборе мусора проходит по всему графу ссылок. Такие ссылки на
    области памяти могут доставить ему немало проблем.

    > Кроме того, необязательно это должен быть указатель.

    > Ведь я предлагал несколько решений. Указатель — только одно из таких
    > решений. Просто Sergey хотел получить именно указатель.

    А что еще? Не делать же Peek(0x1238146) как в Бэйсике

    ЗЫ: я сейчас пишу GC.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 17:28
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Кроме того, необязательно это должен быть указатель.

    >> Ведь я предлагал несколько решений. Указатель — только одно из таких
    >> решений. Просто Sergey хотел получить именно указатель.
    C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике

    А почему бы и нет?
    Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM
    GET(address, variable);

    Разница в том, что присваивание соответствует типу переменной variable.

    C>ЗЫ: я сейчас пишу GC.


    Вот это уже действительно интересно!
    А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть.

    P.S. Если я сегодня вдруг "замолчу" (уже не успею ответить), то отвечу завтра.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 17:47
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVC>>Наивный вопрос: что такое АВ?

    WH>Транслитерация (лень раскладку переключять) сокращения AV от Access Violation

    Спасибо!
    Я, увы, не догадался.

    AVC>>Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.

    WH>А фанаты смаллтолка утверждают что эти системы происходят от смаллтолка...

    Интересно, могут ли фанаты смоллтока подтвердить это, в то время как можно продемонстрировать, что практически все конструкции Java (по крайней мере, первоначальной) имеют аналоги в значительно более раннем языке Оберон, о котором в Sun не могли не знать (т.к. имели лицензию на ETH Oberon)?

    AVC>>Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет.

    WH>А с логикой тут все в порядке. Лично мне Оберон глубоко по барабану(Я сюда просто потрепатся захожу когда работа задалбывает). А тебе и Губанову судя по всему нет. Вот вы и кидаетесь на всех кто высказывает сомнения в том что оберон решит все проблемы человечества.

    Я вроде бы ни на кого не кидаюсь.
    И уж, тем более, никому не навязываю "треп", если он мне не интересен.
    Вообще-то, все было прямо наоборот Вашему утверждению.
    Мне подумалось, что Оберон-система — хорошее решение для некоторых задач.
    Вот я и вынес на обсуждение вопрос: "Есть ли плюсы у Оберона?" (вот так я "на всех набросился").
    Тут-то на мою бедную голову и посыпался град критики.
    Я-де и Рихтера не читал, и т.д. и т.п.
    (Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как Курилка: люблю я его, гада, и все тут.)
    Может быть, это были такие же "праздношатающиеся", как и Вы?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[13]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 24.01.05 18:21
    Оценка:
    AVC пишет:

    >>> Кроме того, необязательно это должен быть указатель.

    >>> Ведь я предлагал несколько решений. Указатель — только одно из таких
    >>> решений. Просто Sergey хотел получить именно указатель.
    > C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике
    > А почему бы и нет?
    > Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM
    >
    >GET(address, variable);
    >
    > Разница в том, что присваивание соответствует типу переменной variable.

    А скорость будет... Представляю себе копирование многомегабайтных
    массивов в видеопамять с помощью Poke'ов.

    > C>ЗЫ: я сейчас пишу GC.

    > Вот это уже действительно интересно!
    > А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть.

    Для встраивания в Mono — там сейчас у них консервативный GC, а я пытаюсь
    написать точный.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 20:32
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>(Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как Курилка: люблю я его, гада, и все тут.)


    Говорил я себе: никогда не пиши второпях, не дави на "клаву", если нет времени подумать!
    Вот и сейчас: взял и оклеветал Курилку ни за что, ни про что!
    Вышел из конторы, и екнуло: это был не Курилка, а Зверек Харьковский со своей статьей "C++ulture".

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[14]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 24.01.05 21:05
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике

    >> А почему бы и нет?
    >> Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM
    >>
    >>GET(address, variable);
    >>
    >> Разница в том, что присваивание соответствует типу переменной variable.
    C>А скорость будет... Представляю себе копирование многомегабайтных
    C>массивов в видеопамять с помощью Poke'ов.

    Вот здесь Вы точно не правы!
    Дело в том, что так называемый модуль SYSTEM (к которому относится процедура GET) — это псевдомодуль, реализуемый компилятором.
    Практически все его функции — встраиваемые, многие из них реализуются одной-единственной машинной инструкцией.
    Мало того, специально для пересылки "многомебайтных массивов" существует процедура MOVE.
    Так что в данном случае Вам как раз гарантирована максимальная эффективность.

    >> C>ЗЫ: я сейчас пишу GC.

    >> Вот это уже действительно интересно!
    >> А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть.
    C>Для встраивания в Mono — там сейчас у них консервативный GC, а я пытаюсь
    C>написать точный.

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 25.01.05 04:49
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".


    Запорожец-лимузин тоже существует. Только это не доказывает, что он годится хоть для какого-то практического использования.
    И вопрос звучит не "КАК это работает", а "где гарантия, что это будет работать НЕ в лабораторных условиях"
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 07:31
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Прекрасно. Мы уже выяснили, что потоки называются в Обероне "активными

    C>объектами". Следующий вопрос: они образуют иерархию?

    Такого ограничения нет. Объекты могут ссылаться друг на друга как им вздумается, хоть циклически хоровод водить. Запутанные связи между ними распутываются автоматически сборщиком мусора.
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 07:47
    Оценка:
    WH>>Я сейчас пишу под .НЕТ который защищен не хуже Оберона и прекрасно понимаю о чем говорю.

    AVC>Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.




    http://www.inr.ac.ru/~info21/motiv.htm

    Проект Оберон оказывает мощное влияние на мировую индустрию программирования: оно прослеживается в мега-проектах Java и .NET корпораций Sun и Microsoft (в Sun изучили коды Оберона еще в 1991 г., задолго до объявления Java, а по сущностным характеристикам языки Java и C# ближе к Оберону, чем к своим синтаксическим предшественникам). Это позволяет говорить о формировании под влиянием Оберона стандартной парадигмы программирования.


    Разработка JIT-компилятора для языка Java по заказу компании Borland была выполнена компанией Oberon microsystems (помните BlackBox?)
    http://www.oberon.ch/references.html

    Borland Entwicklung eines Java Just-In-Time Compiler Back-Ends.

    Re[5]: Как пишут драйверы на safe языках программирования.
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 08:24
    Оценка:
    Драйверы под оберон-системы пишутся на самих оберонах.

    Для этого используют модуль SYSTEM


    http://www.oberon.ethz.ch/SYSTEM.html

    The Module SYSTEM

    ...

    Constants (PC only)
    For the use with SYSTEM.GETREG and SYSTEM.PUTREG, the following integer constants are defined:
    EAX = 8; ECX = 9; EDX = 10; EBX = 11;
    ESP = 12; EBP = 13; ESI = 14; EDI = 15;
    AX = 16; CX = 17; DX = 18; BX = 19;
    SP = 20; BP = 21; SI = 22; DI = 23;
    AL = 24; CL = 25; DL = 26; BL = 27;
    AH = 28; CH = 29; DH = 30; BH = 31;


    ..


    Function procedures
    (* Return the address of the specified variable, parameter or record field. *)
    PROCEDURE ADR (VAR v: Any): LONGINT;

    Remark: Be cautious when using a pointer type! The pointer value is not always the same as the data element's address, as shown in this example:

    VAR p: POINTER TO ARRAY OF x;
    SYSTEM.VAL(LONGINT, p) # SYSTEM.ADR(p[0])

    (* Test bit "n" at the specified address. *)
    PROCEDURE BIT (adr: Address; n: LONGINT): BOOLEAN;

    (* Read an 8-bit value from the specified memory address. *)
    PROCEDURE GET8 (adr: Address): SHORTINT;

    (* Read a 16-bit value from the specified memory address. *)
    PROCEDURE GET16 (adr: Address): INTEGER;

    (* Read a 32-bit value from the specified memory address. *)
    PROCEDURE GET32 (adr: Address): LONGINT;

    (* Return value "x", shifted left "n" bits (may be negative, to shift right). *)
    PROCEDURE LSH (x: IntValue; n: LONGINT): TypeOfX;

    (* Return value "x", rotated left "n" bits (may be negative, to rotate right). *)
    PROCEDURE ROT (x: IntValue; n: LONGINT): TypeOfX;

    (* Type cast. Return the value of "x" interpreted as of type "T", with no conversion. *)
    PROCEDURE VAL (T: AlmostAnyTypeName; x: Any): TypeT;

    SYSTEM.VAL(LONGINT, {0}) is 1, and SYSTEM.VAL(SET, 1) is {0}. Other Oberon compilers (e.g. PowerPC) may behave differently.

    Remark: A warning is issued if the compiler option \w is used.



    ...


    Proper procedures
    (* Read value "v" from the specified memory address. The size of "v" must be 8-, 16- or 32-bits. *)
    PROCEDURE GET (adr: Address; VAR v: BuiltIn);

    (* Copy "n" bytes from address "src" to address "dst".
    Behaviour for overlapping source and destination is not defined. *)
    PROCEDURE MOVE (src, dst: Address; n: LONGINT);

    (* Allocate an untraced block of memory of "n" bytes. *)
    PROCEDURE NEW (VAR v: PTR; n: LONGINT);

    (* Write the value of "x" to the specified memory address. The size of "x" must be 8-, 16- or 32-bits. *)
    PROCEDURE PUT (adr: Address; x: BuiltIn);

    (* Write the lower 8 bits of "x" to the specified memory address. *)
    PROCEDURE PUT8 (adr: Address; x: LONGINT);

    (* Write the lower 16 bits of "x" to the specified memory address. *)
    PROCEDURE PUT16 (adr: Address; x: LONGINT);

    (* Write 32 bits of "x" to the specified memory address. *)
    PROCEDURE PUT32 (adr: Address; x: LONGINT);

    (* Assign the value of the specified register to "v". Note that in some cases
    the dereferencing of "v" may cause other registers to be overwritten. *)
    PROCEDURE GETREG (r: RegNum; VAR v: BuiltIn);

    (* Assign the specified value to the specified register. Note that the evaluation
    of "x" may also change other registers. *)
    PROCEDURE PUTREG (r: RegNum; x: BuiltIn);


    Proper procedures specific to ETH Oberon Native
    (* Perform a port input instruction at the specified I/O address.
    The size of "v" must be 8-, 16- or 32-bits. *)
    PROCEDURE PORTIN (adr: LONGINT; VAR v: BuiltIn);

    (* Perform a port output instruction at the specified I/O address.
    The size of "x" must be 8-, 16- or 32-bits. *)
    PROCEDURE PORTOUT (adr: LONGINT; x: BuiltIn);

    (* Disable interrupts on the current processor. *)
    PROCEDURE CLI ();

    (* Enable interrupts on the current processor. *)
    PROCEDURE STI ();

    (* Halt execution with a TRAP. "n" is an arbitrary integer displayed in the trap viewer.
    Trap numbers in the range -39..27 are pre-defined, and an appropriate message is displayed
    by the trap handler in the System module. The value MAX(INTEGER) is interpreted specially,
    for debugging. A trap viewer is displayed, but execution continues after the HALT. *)
    PROCEDURE HALT (n: LONGINT);

    ...

    и так далее.


    Native Oberon Operating System
    http://www.oberon.ethz.ch/native/
    Re[6]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 08:31
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Какая связь между языками Си/Си++ и драйверами?

    >> Драйверы под оберон-системы пишутся на самих оберонах.

    C>А как суперзащищенный Оберон-драйвер будет работать с портами, IRQ и, не

    C>побоюсь этого слова, указателями?

    Значит если в самом языке нет средств для работы на низком уровне, то он не может на нем работать, так что ли? А вот, например, в языках Си/Си++ нет встроенной возможности для параллельной работы, и что из этого следует? А следует из этого то что используются внешние (по отношению к самому языку программирования) библиотеки.
    Re[6]: Как пишут драйверы на safe языках программирования.
    От: Privalov  
    Дата: 25.01.05 08:34
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    То есть, все-таки, ассемблер.

    If a module source text contains assembler code, the module SYSTEM must be imported to invoke the built-in assembler. It is not permitted to import SYSTEM when creating portable binaries in Oberon for Windows or MacOberon.

    Get some inspiration from the nicely written and informative documentation on the assembler used to teach a course in low-level programming by Jacques Egloff


    А как быть с этим?

    Драйверы под оберон-системы пишутся на самих оберонах. (c) Сергей Губанов здесь

    Re[15]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 08:39
    Оценка:
    AVC пишет:

    > C>А скорость будет... Представляю себе копирование многомегабайтных

    > C>массивов в видеопамять с помощью Poke'ов.
    > Вот здесь Вы точно не правы!
    > Дело в том, что так называемый модуль SYSTEM (к которому относится
    > процедура GET) — это псевдомодуль, реализуемый компилятором.
    > Практически все его функции — встраиваемые, многие из них реализуются
    > одной-единственной машинной инструкцией.

    Эффективное копирование он не сможет реализовать.

    > Мало того, специально для пересылки "многомебайтных массивов"

    > существует процедура MOVE.
    > Так что в данном случае Вам как раз гарантирована максимальная
    > эффективность.

    Ага, а где секьюрити, и все такое?

    > C>Для встраивания в Mono — там сейчас у них консервативный GC, а я

    > пытаюсь
    > C>написать точный.
    > Хотелось бы впоследствии узнать, удалась ли Ваша затея, и какие
    > "подводные камни" Вам пришлось преодолеть.
    > Несмотря на расхождение во взглядах, мне всегда интересна точка зрения
    > человека, делающего что-то самостоятельно.

    Моя затея, ничего особого не представляет — просто очередной GC. Просто
    интересен сам процесс ее реализации.

    > Мой внезапный интерес к Оберону основан на практических мотивах: кроме

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

    А нафига маленьким девайсам ОС? А если уж нужна — welcom to WindRiver
    (ихняя ОС даже на Марсе работает). Но использовать Oberon...

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 08:40
    Оценка:
    Сергей Губанов пишет:

    > C>Прекрасно. Мы уже выяснили, что потоки называются в Обероне "активными

    > C>объектами". Следующий вопрос: они образуют иерархию?
    > Такого ограничения нет. Объекты могут ссылаться друг на друга как им
    > вздумается, хоть циклически хоровод водить. Запутанные связи между
    > ними распутываются автоматически сборщиком мусора.

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 08:43
    Оценка:
    Сергей Губанов пишет:

    > C>А как суперзащищенный Оберон-драйвер будет работать с портами, IRQ

    > и, не
    > C>побоюсь этого слова, указателями?
    > Значит если в самом языке нет средств для работы на низком уровне, то
    > он не может на нем работать, так что ли?

    Обычно может, но с диким overhead'ом и полной непригодностью для
    низкоуровнквых задач. Что-то драйверов на VB не видно, хотя теоретически
    они возможны.

    > А вот, например, в языках Си/Си++ нет встроенной возможности для

    > параллельной работы, и что из этого следует? А следует из этого то что
    > используются внешние (по отношению к самому языку программирования)
    > библиотеки.

    В С++ есть все средства для добавления параллельности, но вот в Обероне
    нет средств для серьезного системного программирования: нет изоляции,
    привилегий, и т.п.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 08:50
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>после слова библиотеки следовало бы поставить не точку, а запятую, и

    S>продолжить:
    S>...которые позволяют похерить систему безопасности и делать то же самое, что
    S>возможно делать на ассемблере или С — испортить любой загруженный модуль,
    S>случайно потереть все данные на диске и т.д.

    Ответ:
    http://www.rsdn.ru/Forum/Message.aspx?mid=1002532&amp;only=1
    Автор: Сергей Губанов
    Дата: 25.01.05
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 08:52
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Обычно может, но с диким overhead'ом и полной непригодностью для

    C>низкоуровнквых задач.


    Модуль SYSTEM является встроенным в компилятор. То есть это он только кажется модулем, но все его процедуры на самом деле "инлайняться". Короче, оверхеда нет.
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 25.01.05 08:57
    Оценка:
    Hello, Сергей!
    You wrote on Tue, 25 Jan 2005 08:50:06 GMT:

    S>> после слова библиотеки следовало бы поставить не точку, а запятую, и

    S>> продолжить:
    S>> ...которые позволяют похерить систему безопасности и делать то же
    S>> самое, что возможно делать на ассемблере или С — испортить любой
    S>> загруженный модуль, случайно потереть все данные на диске и т.д.

    СГ> Ответ:

    СГ> http://www.rsdn.ru/Forum/Message.aspx?mid=1002532&amp;only=1
    Автор: Сергей Губанов
    Дата: 25.01.05


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

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[8]: Как пишут драйверы на safe языках программирования.
    От: Sergey Россия  
    Дата: 25.01.05 09:00
    Оценка:
    Hello, Сергей!
    You wrote on Tue, 25 Jan 2005 08:46:34 GMT:

    S>> А есть средства, запрещающие использовать этот модуль простым смертным?

    S>> Потому что с его помощью систему в капусту нашинковать ничуть не
    S>> сложнее, чем с помощью С или ассемблера.

    СГ> Дело не в том что что-то сделать можно или нельзя, а втом, что работая

    СГ> на Си это можно сделать НЕЧАЯННО, а работая на safe языке это
    СГ> можно сделать только НАМЕРЕННО (намеренно используя модуль
    СГ> SYSTEM).

    Не, не так. В обероне тоже можно НЕЧАЯННО ошибиться, намеренно
    используя модуль SYSTEM.

    СГ> Отсюда вывод — для того чтобы быть в полной безопасности:


    СГ> А) В Оберонах: никогда не пользуйтесь чужими непроверенными

    СГ> программами импортирующими модуль SYSTEM.

    Я не удивлюсь, если вдруг окажется, что его можно проимпортировать так, чтоб
    никто не догадался

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey J. A. Беларусь  
    Дата: 25.01.05 09:04
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим.


    "Оберон видиш ? А он есть !" (почти C)
    Я- свихнувшееся сознание Джо
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 09:13
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".

    Д>Запорожец-лимузин тоже существует. Только это не доказывает, что он годится хоть для какого-то практического использования.
    Д>И вопрос звучит не "КАК это работает", а "где гарантия, что это будет работать НЕ в лабораторных условиях"

    Работает же.
    Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.
    Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.
    В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[8]: Как пишут драйверы на safe языках программирования.
    От: Cyberax Марс  
    Дата: 25.01.05 09:22
    Оценка:
    Сергей Губанов пишет:

    > S>А есть средства, запрещающие использовать этот модуль простым смертным?

    > S>Потому что с его помощью систему в капусту нашинковать ничуть не
    > сложнее,
    > S>чем с помощью С или ассемблера.
    > Дело не в том что что-то сделать можно или нельзя, а втом, что работая
    > на Си это можно сделать *НЕЧАЯННО*, а работая на safe языке это можно
    > сделать только *НАМЕРЕННО* (намеренно используя модуль SYSTEM).

    И работая на безопасном языке это вполне можно сделать нечаянно
    (ухмыляясь и смотря как сосед использует мои JNI-обертки).

    > Отсюда вывод — для того чтобы быть в полной безопасности:

    > А) *В Оберонах*: никогда не пользуйтесь чужими непроверенными
    > программами импортирующими модуль SYSTEM.

    Так чего же — ничем не пользоваться?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 09:22
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Интересно, могут ли фанаты смоллтока подтвердить это, в то время как можно продемонстрировать, что практически все конструкции Java (по крайней мере, первоначальной) имеют аналоги в значительно более раннем языке Оберон, о котором в Sun не могли не знать (т.к. имели лицензию на ETH Oberon)?

    Это ты у них спрашивай
    Re[16]: С# vs Java
    Автор: WFrag
    Дата: 30.12.04
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 09:23
    Оценка:
    Sergey пишет:

    > Не, на самм деле это правильный подход. На практике от криво написанных

    > дров/ядра не спасает никакое разделение адресных пространств или любые
    > другие способы защиты — хотя бы просто потому, что в системе обязательно
    > найдутся места, которые как раз за эту защиту и отвечают, и вот они-то и
    > окажутся уязвимы.

    В QNX'е их код — около 100Кб, его много раз просматривали, проверяли и
    тестировали. Все остальное — контролируется ядром.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 09:26
    Оценка:
    Сергей Губанов пишет:

    > C>Обычно может, но с диким overhead'ом и полной непригодностью для

    > C>низкоуровнквых задач.
    > Модуль SYSTEM является встроенным в компилятор. То есть это он только
    > кажется модулем, но все его процедуры на самом деле "инлайняться".
    > Короче, оверхеда нет.

    Что, мне опять запускать XDS и сравнивать то, что он нагенерит, с
    результатом компиляции С? Не будет оно оптимальным, даже близко не будет.

    Кто-то там, я помню, кричал про трехкратное превосходство XDS над С в
    скорости, но так и не привел версии и ключей компилятора.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 09:27
    Оценка:
    Sergey пишет:

    > СГ> Ответ:

    > СГ> http://www.rsdn.ru/Forum/Message.aspx?mid=1002532&amp;only=1
    Автор: Сергей Губанов
    Дата: 25.01.05

    > <http://www.rsdn.ru/Forum/Message.aspx?mid=1002532&amp;only=1&gt;
    Автор: Сергей Губанов
    Дата: 25.01.05

    > Ага, а в третьей нетвари можно было пользоваться только
    > сертифицированными
    > NLM'ами, и все тоже работало прекрасно, причем гораздо шустрей, чем любая
    > другая операционка. Притом что использовалось общее для всех пространств
    > адресное пространство и невытесняющая многозадачность.

    А как оно падало на сертефицированном BTrieve при вполне нормальных
    запросах — просто сказка...

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 09:29
    Оценка:
    AVC пишет:

    > Работает же.

    > Честно говоря, "рука уже устала" писать одно и то же: Оберон
    > используется в космической (NASA и т.д.), авиационной (Boeing и т.д.),
    > сферах, сфере атомной энергетики, где ответственность весьма высока.

    ГДЕ? Не слышал и не видел.

    > Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто

    > *запрещено*.

    Ой, ой, ой. Рассказать что на марсоходах работает?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[16]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 09:35
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Дело в том, что так называемый модуль SYSTEM (к которому относится

    >> процедура GET) — это псевдомодуль, реализуемый компилятором.
    >> Практически все его функции — встраиваемые, многие из них реализуются
    >> одной-единственной машинной инструкцией.
    C>Эффективное копирование он не сможет реализовать.

    Нет, ну это уже просто слезы!
    Ну, не сможет и все!
    Наверное, по определению. Угадал?

    >> Мало того, специально для пересылки "многомебайтных массивов"

    >> существует процедура MOVE.
    >> Так что в данном случае Вам как раз гарантирована максимальная
    >> эффективность.
    C>Ага, а где секьюрити, и все такое?

    SYSTEM.MOVE существует специально для поддержки системного программирования, на том уровне, где еще нет типов.
    Обычный же программист просто присваивает одной переменной значение другой.
    (Ведь Вы же не просто пересылаете данные, а, наверное, из одной переменной в другую.)
    Полная защита. А где-то внизу под этим — SYSTEM.MOVE.

    >> Несмотря на расхождение во взглядах, мне всегда интересна точка зрения

    >> человека, делающего что-то самостоятельно.
    C>Моя затея, ничего особого не представляет — просто очередной GC. Просто
    C>интересен сам процесс ее реализации.

    Так ведь и я написал, что мне именно интересно, а не "гениально! great! manifique!"

    C>А нафига маленьким девайсам ОС? А если уж нужна — welcom to WindRiver

    C>(ихняя ОС даже на Марсе работает). Но использовать Oberon...

    Да-да, продолжайте мысль...
    Наверное, что-то вроде того, что Oberon не может работать на Марсе. По определению.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 09:35
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:


    >> Работает же.

    >> Честно говоря, "рука уже устала" писать одно и то же: Оберон
    >> используется в космической (NASA и т.д.), авиационной (Boeing и т.д.),
    >> сферах, сфере атомной энергетики, где ответственность весьма высока.

    C>ГДЕ? Не слышал и не видел.


    И после это Вы еще тут бочку на обероны катите, а сами, оказывается, просто не слышали и не видели...
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 09:39
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Кто-то там, я помню, кричал про трехкратное превосходство XDS над С в

    C>скорости, но так и не привел версии и ключей компилятора.

    Не "кто-то там", а уважаемый AVC. Это Ваше сообщение — хамское. Настройки компилятора описаны были (по умолчанию).
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 25.01.05 09:41
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>И после это Вы еще тут бочку на обероны катите, а сами, оказывается, просто не слышали и не видели...


    Несколько лет назад видел публикации, что в космос летает математика, написанная на C в среде MS DOS. Встречалось что-то о разработке транслятора PL/1 для бортовых систем. Об Обероне — ни слова. Может, просветите?
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 25.01.05 09:45
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    P>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>И после это Вы еще тут бочку на обероны катите, а сами, оказывается, просто не слышали и не видели...


    P>Несколько лет назад видел публикации, что в космос летает математика, написанная на C в среде MS DOS. Встречалось что-то о разработке транслятора PL/1 для бортовых систем. Об Обероне — ни слова. Может, просветите?



    "Рука устала"

    Начать отсюда:

    http://www.inr.ac.ru/~info21/

    далее по всем ссылкам...
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 09:47
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Что, мне опять запускать XDS и сравнивать то, что он нагенерит, с

    C>результатом компиляции С? Не будет оно оптимальным, даже близко не будет.

    C>Кто-то там, я помню, кричал про трехкратное превосходство XDS над С в

    C>скорости, но так и не привел версии и ключей компилятора.

    Это, уж как бы поделикатнее это сказать... вранье-с.
    http://www.rsdn.ru/Forum/Message.aspx?mid=995268&amp;only=1
    Автор: AVC
    Дата: 19.01.05

    Обратите внимание, дожидается Вашего ответа с 19 января.
    Повторяю также, что ключи компиляции Dry.mod находятся в самом исходном файле.
    Я то попросту подумал, что Вам неловко будет повторять мысль, что MSVC 8 (beta 1!!! ) в 12(!) раз эффективнее, чем MSVC 6. Ан, нет...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 09:57
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Не "кто-то там", а уважаемый AVC. Это Ваше сообщение — хамское. Настройки компилятора описаны были (по умолчанию).


    Сергей, дай пожму Твою мужественную руку!
    Вот так. Да!
    Уважаемый AVC.
    Приятно.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 25.01.05 10:13
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.


    Где-то я уже это слышал... практически слово в слово.

    AVC>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.

    AVC>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.

    Ну если тебе это душу греет.. расслабься и be happy, и не обращай внимания, что в "детской песочнице" крутятся практически все деньги ИТ-индустрии.
    Что касается меня, то я вижу здесь просто разработку программ с предельно простым функционалом, которые работают в теплично простых условиях, отлаживаются и вылизываются очень-очень долго... программы с крайне низким коэффициентом функционал/затраты.. и при этом они все равно не по детски глючат!
    Скажу прямо — я не считаю такие разработки признаком неимоверной крутизны языка.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 25.01.05 10:13
    Оценка:
    Здравствуйте, AVC, Вы писали:

    СГ>>Не "кто-то там", а уважаемый AVC. Это Ваше сообщение — хамское. Настройки компилятора описаны были (по умолчанию).


    AVC>Сергей, дай пожму Твою мужественную руку!

    AVC>Вот так. Да!
    AVC>Уважаемый AVC.
    AVC>Приятно.

    Спелись
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    AVK Blog
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 10:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVC>>Интересно, могут ли фанаты смоллтока подтвердить это, в то время как можно продемонстрировать, что практически все конструкции Java (по крайней мере, первоначальной) имеют аналоги в значительно более раннем языке Оберон, о котором в Sun не могли не знать (т.к. имели лицензию на ETH Oberon)?

    WH>Это ты у них спрашивай
    WH>Re[16]: С# vs Java
    Автор: WFrag
    Дата: 30.12.04


    Речь идет об отдельно взятой "фиче" (так в тексте) — Hotspot.
    Я же говорю именно о конструкциях языка Java.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 10:47
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, AVC, Вы писали:


    AVC>>Работает же.

    WH>Ну и мои серваки на С++ крутятся без сбоев...

    Так и я пишу на Си++.
    И мои программы работают годами без малейшего человеческого вмешательства.
    Или Вы думаете, что мне нравится Оберон потому, что я не могу писать на Си++?
    Только разве это аргумент?
    У некоторых и ассемблерные программы работают превосходно.
    Давайте все писать на ассемблере?

    AVC>>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.

    WH>Весьма "разумно" особенно учитывая что типизация в С++ сильнее чем в обероне... То что ее можно послать другой вопрос... в обероне (как мы выяснили
    Автор: AVC
    Дата: 24.01.05
    ) тоже можно...


    В Си++ типизация сильнее, чем в Обероне?
    Это Вы баек о пользе шаблонов в Си++ наслушались?
    А как Вам конструкции вида
    int foo(void *p)
    {
      return ((int (*)())p)();
    }

    ?
    Эх, нет сейчас под рукой Рихтера (того самого, которого я, как мне говорят, не читал ).
    Там такой системный код с приведением указателей...
    Издано у нас под вывеской ДЛЯ ПРОФЕССИОНАЛОВ!
    Там он еще просит "профессионалов" не передавать другому потоку указатель на стековую переменную...
    У меня в подъезде перед лифтом висит надпись: "Перед тем, как войти в кабину лифта, УБЕДИТЕСЬ, ЧТО ОНА НАХОДИТСЯ ПЕРЕД ВАМИ!"
    Примерно тот же уровень профессионализма...

    AVC>>В принципе, Си++ — язык для детской песочницы.

    WH>Такое себе даже фанаты C# не позволяют.

    Зато позволяют себе правительства Канады и Великобритании.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 11:18
    Оценка:
    Сергей Губанов пишет:

    > C>Кто-то там, я помню, кричал про трехкратное превосходство XDS над С в

    > C>скорости, но так и не привел версии и ключей компилятора.
    > Не "кто-то там", а уважаемый AVC. Это Ваше сообщение — хамское.
    > Настройки компилятора описаны были (по умолчанию).

    И чего тут хамского? Неужели сложно было прислать командную строчку? Тем
    более, что понятие "по умолчанию" — весьма растяжимое. Debug-версия
    действительно может работать в разы медленнее XDS (я это показал), но
    Release-версия иногда в 20-30 раз быстрее отладочной (в частности, во
    много раз быстрее XDSной).

    И я *уверен*, что XDS не сможет сгенерировать оптимальный код в данном
    случае.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 11:25
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Это, уж как бы поделикатнее это сказать... вранье-с.

    AVC>http://www.rsdn.ru/Forum/Message.aspx?mid=995268&amp;only=1
    Автор: AVC
    Дата: 19.01.05

    Ты бы всетки ключики привел. От них много чего зависит. Что трудно Copy-Paste сделать?
    AVC>Повторяю также, что ключи компиляции Dry.mod находятся в самом исходном файле.
    Это типа круто? А по моему ключи компиляции должны лежать в файле проекта, а в исходниках им делать нечего.
    AVC>Я то попросту подумал, что Вам неловко будет повторять мысль, что MSVC 8 (beta 1!!! ) в 12(!) раз эффективнее, чем MSVC 6. Ан, нет...
    Теоритически это возможно но на практике скорей всего у тебя что-то не то с ключами компилятора.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 11:33
    Оценка:
    AVC пишет:

    > C>Что, мне опять запускать XDS и сравнивать то, что он нагенерит, с

    > C>результатом компиляции С? Не будет оно оптимальным, даже близко не
    > будет.
    > C>Кто-то там, я помню, кричал про трехкратное превосходство XDS над С в
    > C>скорости, но так и не привел версии и ключей компилятора.
    > Это, уж как бы поделикатнее это сказать... вранье-с.
    > http://www.rsdn.ru/Forum/Message.aspx?mid=995268&amp;only=1
    Автор: AVC
    Дата: 19.01.05

    > <http://www.rsdn.ru/Forum/Message.aspx?mid=995268&amp;only=1&gt;
    Автор: AVC
    Дата: 19.01.05

    > Обратите внимание, дожидается Вашего ответа с 19 января.

    Извиняюсь, не увидел сообщение. VC6 у меня нет, есть VC7.1 и VC8. Ключи
    такие:
    ==============
    /Ox /Og /Ob2 /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS"
    /FD /EHsc /MT /GS /Fo"Release/" /Fd"Release/vc80.pdb" /W3 /nologo /c
    /Wp64 /Zi /TP
    ==============
    Вдобавок, в коде теста тоже нужно пару мест поправить.

    > Повторяю также, что ключи компиляции *Dry.mod* находятся в самом

    > исходном файле.
    > Я то попросту подумал, что Вам неловко будет повторять мысль, что MSVC
    > 8 (beta 1!!! ) в *12*(!) раз эффективнее, чем MSVC 6. Ан, нет...

    Вполне может быть. VC8 заточена под новые процессоры, в отличие от
    древней VC6.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 11:45
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, AVC, Вы писали:


    AVC>>Это, уж как бы поделикатнее это сказать... вранье-с.

    AVC>>http://www.rsdn.ru/Forum/Message.aspx?mid=995268&amp;only=1
    Автор: AVC
    Дата: 19.01.05

    WH>Ты бы всетки ключики привел. От них много чего зависит. Что трудно Copy-Paste сделать?

    Так у Cyberax есть и файл с ключиками, и компилятор XDS. Он просто забыл в этот файл посмотреть.
    Но, по просьбе трудящихся, все же привожу эти ключи:

    <* IF __GEN_X86__ THEN *>
    <*+NOPTRALIAS*>
    <*-SPACE*>
    <*-GENHISTORY*>
    <*+DOREORDER*>
    <* END *>
    <* ALIGNMENT="4"*>
    <*+PROCINLINE*>
    <*-CHECKINDEX*>
    <*-CHECKRANGE*>
    <*-CHECKNIL*>
    <*-IOVERFLOW*>
    <*-COVERFLOW*>
    <*-GENDEBUG*>
    <*-LINENO*>


    Для Visual C++ я просто выбрал Release/maximize speed.
    Это вылилось в такой набор ключей:

    /nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /Fp"Release/Dry.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c

    На случай "плохого" выбора ключей, попросил Cyberax выбрать ключи самому.

    AVC>>Повторяю также, что ключи компиляции Dry.mod находятся в самом исходном файле.

    WH>Это типа круто? А по моему ключи компиляции должны лежать в файле проекта, а в исходниках им делать нечего.

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

    AVC>>Я то попросту подумал, что Вам неловко будет повторять мысль, что MSVC 8 (beta 1!!! ) в 12(!) раз эффективнее, чем MSVC 6. Ан, нет...

    WH>Теоритически это возможно но на практике скорей всего у тебя что-то не то с ключами компилятора.

    У меня?!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 25.01.05 11:46
    Оценка:
    Cyberax пишет:

    > Извиняюсь, не увидел сообщение. VC6 у меня нет, есть VC7.1 и VC8. Ключи

    > такие:
    > ==============
    > /Ox /Og /Ob2 /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS"
    > /FD /EHsc /MT /GS /Fo"Release/" /Fd"Release/vc80.pdb" /W3 /nologo /c
    > /Wp64 /Zi /TP
    > ==============
    > Вдобавок, в коде теста тоже нужно пару мест поправить.

    Вдогонку, попытался вникнуть в этот тест. Результат: ну и &%@#&$% же
    это. Строки используются C-шные, без всякой оптимизации. Большую часть
    времени в func0 тратится на strcmp и т.д. Простая замена Сшных строк на
    что-нибудь поприличнее даст еще больший прирост скорости.

    Работу с массивы можно тоже пооптимизировать (boost::multi_array — наш
    друг).

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 11:49
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>В Си++ типизация сильнее, чем в Обероне?

    Да.
    AVC>Это Вы баек о пользе шаблонов в Си++ наслушались?
    Нет. Я их распространяю. Ибо сам активно использую шаблоны и прекрасно знаю о чем говорю.
    AVC>А как Вам конструкции вида
    [q]WH>>Весьма "разумно" особенно учитывая что типизация в С++ сильнее чем в обероне... То что ее можно послать другой вопрос... в обероне (как мы выяснили
    Автор: AVC
    Дата: 24.01.05
    ) тоже можно...

    (int (*)())

    это посылание типизации

    За подобный код нужно трывать руки и навсегда отлучать от компилятора. Исключения состовляют лишь библиотеки низкого уровня при этом их интерфейс должен быть таким чтобы исключить привидение не к тому типу. См boost::function там в нутри используются подобные фокусы но все сделано так что при использовании самого шаблоны boost::function типизация полностью контролируется компилятором.
    А если подобные фокусы не загнаны под пулинепробиваемый интерфейс то автора в кандалы и в сибирь снег убирать.
    К томуже такое посылание типов не чуждо и оберону... Так шта...

    AVC>Зато позволяют себе правительства Канады и Великобритании.

    Это их проблемы. А кстати они раздрешают BrainFack? Или WhiteSpace? Это же супер языки... такие мощьные концепции!
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 12:04
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Извиняюсь, не увидел сообщение. VC6 у меня нет, есть VC7.1 и VC8. Ключи

    C>такие:
    C>==============
    C>/Ox /Og /Ob2 /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS"
    C>/FD /EHsc /MT /GS /Fo"Release/" /Fd"Release/vc80.pdb" /W3 /nologo /c
    C>/Wp64 /Zi /TP
    C>==============
    C>Вдобавок, в коде теста тоже нужно пару мест поправить.

    Просьба: если есть возможность, отправьте мне исправленный Вами текст по адресу:

    (чтобы не было расхождений).
    А я посмотрю, какой результат у меня получится.
    Чем Бог не шутит...

    C>Вполне может быть. VC8 заточена под новые процессоры, в отличие от

    C>древней VC6.

    Не верю! (с) Станиславский
    Впрочем, при первой же возможности проведу эксперимент.
    У меня тут в эпсилон-окрестности 8-й версии пока ни у кого нет.
    Возможно, потому что мы PC используем в основном для кросс-отладки.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 12:44
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, AVC, Вы писали:


    AVC>>В Си++ типизация сильнее, чем в Обероне?

    WH>Да.
    AVC>>Это Вы баек о пользе шаблонов в Си++ наслушались?
    WH>Нет. Я их распространяю. Ибо сам активно использую шаблоны и прекрасно знаю о чем говорю.

    Логика учит : чтобы утверждать, что типизация в Си++ сильнее, чем в Обероне, надо хорошо представлять себе не только Си++, но и Оберон.
    Или на Си++ программистов это уже не распространяется?

    AVC>>А как Вам конструкции вида

    WH>[q]WH>>Весьма "разумно" особенно учитывая что типизация в С++ сильнее чем в обероне... То что ее можно послать другой вопрос... в обероне (как мы выяснили
    Автор: AVC
    Дата: 24.01.05
    ) тоже можно...


    Зря Вы за это "уцепились". Получается как в известной пословице про "услышанный звон".
    В указанном Вами месте я отвечал на вопрос, если в Обероне в принципе средства низкоуровневого программирования.
    Но дело в том, что в Обероне средства низкоуровневого программирования отделены от основного языка.
    Необходимо использовать (псевдо)модуль SYSTEM, чего нельзя скрыть, и что может быть и запрещено, если это потребуется для безопасности системы.
    А в Си/Си++ — это не так.
    Там без приведения типов — никуда. Просто Вы пытаетесь спрятать их подальше (в boost::function, к примеру), чтобы глаза не мозолили.
    Мало того, что это не решает проблему в корне, но еще и ухудшает читабельность.
    С новыми наворотами boost Си++ уже не три года изучать надо, как по средней статистике, а еще больше.

    WH>
    WH>(int (*)()) 
    WH>

    WH>это посылание типизации
    WH>За подобный код нужно трывать руки и навсегда отлучать от компилятора. Исключения состовляют лишь библиотеки низкого уровня при этом их интерфейс должен быть таким чтобы исключить привидение не к тому типу. См boost::function там в нутри используются подобные фокусы но все сделано так что при использовании самого шаблоны boost::function типизация полностью контролируется компилятором.
    WH>А если подобные фокусы не загнаны под пулинепробиваемый интерфейс то автора в кандалы и в сибирь снег убирать.

    Я уже заметил, что у программистов на Си++ мышление повернуто несколько в садистскую плоскость: кого/что убить... в кандалы... в Сибирь...

    Еще стандартны фразы о "кривых ручках" и "ошибках в ДНК".
    Только все эти заклинания слабо им помогают...

    AVC>>Зато позволяют себе правительства Канады и Великобритании.

    WH>Это их проблемы. А кстати они раздрешают BrainFack? Или WhiteSpace? Это же супер языки... такие мощьные концепции!

    Наверное, Канаде и Англии плохо приходится, если у них такие ПРОБЛЕМЫ!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[14]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewJD США  
    Дата: 25.01.05 12:58
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>В исходный код теста Drystone нельзя вносить ни каких изменений! Иначе он теряет свой статус. Любое изменение превращает его в совершенно другой тест. (Ну, естественно, поменять количество иттераций можно)


    СГ>Например, именно поэтому нельзя написать исходник Drystone для Component Pascal — буквальный перевод со старого Паскаля невозможен (не будет компилироваться), а "вольная интерпретация" превращает его в другой тест не имеющий признанного статуса теста Drystone.


    Круто, а если бы они там Sleep местами повставляли ?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[15]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 12:59
    Оценка:
    Здравствуйте, AndrewJD, Вы писали:

    AJD>Круто, а если бы они там Sleep местами повставляли ?


    Ну, если бы...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 14:07
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>==============

    C>/Ox /Og /Ob2 /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS"
    C>/FD /EHsc /MT /GS /Fo"Release/" /Fd"Release/vc80.pdb" /W3 /nologo /c
    C>/Wp64 /Zi /TP
    C>==============
    C>Вдобавок, в коде теста тоже нужно пару мест поправить.

    Исправил заголовки функций (правда, далеко не в двух местах).
    Использовал Ваши ключи.
    Все, кроме /Wp64, /GS, /GL (6-й компилятор их не знает).
    Результат: 3076923.
    (против 8000000 у XDS).
    Размер файла: 86065.

    Наверное, надо искать MSVC 8.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 25.01.05 14:27
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH> Хотя про Канадских программистов расказывают такое... что они якобы хуже Индусов...

    Watcom, Maple, QNX... пожалуй, достаточно.
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 14:45
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVC>>Логика учит : чтобы утверждать, что типизация в Си++ сильнее, чем в Обероне, надо хорошо представлять себе не только Си++, но и Оберон.

    WH>А что его представлять? Примитивный язык в которм коллекции либо полиморфные либо копипастные. Те либо дублирование кода, а это дублирование ошибок... либо все проверки в рантайме медленно и не надежно.
    WH>А то что нет злых кастов на уровне языка так это дело поправляется (псевдо)модулем SYSTEM...
    WH>Да и без этого можно систему завалить. Делаем запутаный граф объектов которой в какомто левом модуле(который SYSTEM не использует)цепляется за глобальную переменную и привет... ГЦ умер...

    Шаблонов, правда, в Обероне нет (да и не надо, хотя и есть версии Оберона, которые их поддерживают).
    Все же остальные Ваши утверждения — пальцем в небо.
    Особенно смешна идея зацепить граф объектов за глобальную переменную.
    Т.е. об указателях в Обероне Вы не знаете ничего.

    AVC>>В указанном Вами месте я отвечал на вопрос, если в Обероне в принципе средства низкоуровневого программирования.

    WH>Возможность есть. А заначит есть возможность напакостить.

    Если будет важна безопасность, Вам возможности "напакостить" не предоставят.

    AVC>>Но дело в том, что в Обероне средства низкоуровневого программирования отделены от основного языка.

    WH>Но это не мешает их использовать.

    Если они будут запрещены на этом уровне, Вы не сможете их использовать.

    AVC>Мало того, что это не решает проблему в корне, но еще и ухудшает читабельность.

    WH>Ты это можешь расказывать тем кто на С++ не писал.

    Вранье!
    Это уже начинает утомлять.

    AVC>>С новыми наворотами boost Си++ уже не три года изучать надо, как по средней статистике, а еще больше.

    WH>А! Ну-ну. Если человек не совсем пробка он у меня через полгода на С++ с STL и boost'ом писать будет.
    WH>А пробка и на обероне таких дров наломает что мало не покажется.

    Ну да, вечная песня о крутости программистов на Си/Си++.
    То-то я вечно застаю их сидящими в отладчиках.

    AVC>>Я уже заметил, что у программистов на Си++ мышление повернуто несколько в садистскую плоскость: кого/что убить... в кандалы... в Сибирь...

    WH>В данный момент я программист на C#. И вобще я могу писать на чем угодно.

    Вы хотите меня ознакомить с Вашим резюме?

    WH>Просто раздаражают люди которые пытаются навязать какуюто поделку в качестве панацеи. Вот и получаются резкии фразы.


    Учитывая, что, как выяснилось, об Обероне Вы знаете мало, Ваши резкие фразы несколько преждевременны и говорят, скорее, о плохих нервах.
    К тому же, я не помню, чтобы я говорил об Обероне как о панацее или пытался кому-нибудь его навязать.
    Говорил только о его применимости в некоторых случаях.

    AVC>>Только все эти заклинания слабо им помогают...

    WH>Мне они не нужны. У меня проблем нет.

    Рад за Вас!

    AVC>>Наверное, Канаде и Англии плохо приходится, если у них такие ПРОБЛЕМЫ!

    WH>Не знаю. Я там небыл. Хотя про Канадских программистов расказывают такое... что они якобы хуже Индусов...

    Логика понятна. Раз канадское правительство наложило ограничения на применение Си++, то и канадские программисты — плохие.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 25.01.05 15:16
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, AVC, Вы писали:


    AVC>Приношу Курилке мои извинения (даже если он и вправду любит Си++ такой же безумной любовью, как и Зверек Харьковский )!


    Принимается, даже несмотря на то, что я плюсы люблю, незнаю правда про безумность
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 25.01.05 15:22
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    AVC>>Приношу Курилке мои извинения (даже если он и вправду любит Си++ такой же безумной любовью, как и Зверек Харьковский )!

    К>Принимается, даже несмотря на то, что я плюсы люблю, незнаю правда про безумность

    Спасибо!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 16:14
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Шаблонов, правда, в Обероне нет (да и не надо,

    А ну-ну...
    AVC>хотя и есть версии Оберона, которые их поддерживают).
    Тем лучше.
    AVC>Все же остальные Ваши утверждения — пальцем в небо.
    Правда?
    AVC>Особенно смешна идея зацепить граф объектов за глобальную переменную.
    AVC>Т.е. об указателях в Обероне Вы не знаете ничего.
    ГЦ он и в африке ГЦ и сыпится на хитрых графах которые цепляются за стек или статические переменные очень хорошо.

    AVC>Если будет важна безопасность, Вам возможности "напакостить" не предоставят.

    При жилании можно напакостить всегда. А по ошибки это еще проще.

    AVC>Если они будут запрещены на этом уровне, Вы не сможете их использовать.

    А какже SYSTEM? Или модули использующие его?

    AVC>Вранье!

    AVC>Это уже начинает утомлять.
    Это boost::function уменьшает читабельность? Вот это действительно вранье.

    AVC>Ну да, вечная песня о крутости программистов на Си/Си++.

    Ну да вечная песьня об убогости С++... но почемуто у меня с ним проблем не больше чем у меня сейчас с C#.
    AVC>То-то я вечно застаю их сидящими в отладчиках.
    Сейчас (работая на C#) я в отладчике провожу времени столькоже как и при работе на С++.

    AVC>Учитывая, что, как выяснилось, об Обероне Вы знаете мало,

    О! Да ты знаешь что я знаю? Ты телепат?
    AVC>Ваши резкие фразы несколько преждевременны и говорят, скорее, о плохих нервах.
    Да ты еще и психолог?
    AVC>К тому же, я не помню, чтобы я говорил об Обероне как о панацее или пытался кому-нибудь его навязать.
    Прямо может и не говорил но как еще расценивать заявления что на обероне нельзя накосячить?
    AVC>Говорил только о его применимости в некоторых случаях.
    О! Уже прогрес.

    WH>>Не знаю. Я там небыл. Хотя про Канадских программистов расказывают такое... что они якобы хуже Индусов...

    AVC>Логика понятна. Раз канадское правительство наложило ограничения на применение Си++, то и канадские программисты — плохие.
    Не вижу связи между моей фразой и твоим выводом.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 25.01.05 16:40
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Дело в том, что указатель в Обероне может указывать только на объект, расположенный в куче и не может указывать ни на стековую, ни на статическую переменную.

    AVC>Указатель получает свое значение только следующими путями:

    AVC>1) NEW(p) — создать новый объект;

    AVC>2) p := q; присвоить p значение другого валидного указателя q;
    AVC>3) p := NIL; указатель никуда больше не указывает.

    AVC>В начале указатель инициализирован NIL.

    AVC>Т.е. указатель либо указывает на объект в куче, либо равен NIL.
    AVC>И как же нам "зацепить" граф объектов за стек или статические переменные?
    ГЦ обыкновенный. Такойже как и везде. И валистся аналогично. А под словом зацепить за стек или статическую переменную я имел в виду что на стеке или в качастве статичекой переменной делаем указатель и присваиваем ему указатель на один из объектов графа объектов(которые ссылаются друг на друга)
    А теперь забываем исделать
    AVC>3) p := NIL; указатель никуда больше не указывает.
    Все! Граф будет жить вечно. И такие ошибки уже были например в RSDN@Home(та софтина в которой я пишу этот пост) Да да утечки памяти в программе с ГЦ это реальность. А про утечки внешних ресурсов я вобще молчу...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: DJ KARIES Россия  
    Дата: 25.01.05 21:35
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Насколько я понял, в Обероне каждый модуль может быть загружен только один раз. Соответственно, мне кажется, что будут проблемы из разряда того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту возможность у всех остальных пользователей...

    На атомных станциях не запускают Фотошопов.
    Ибо дорого.

    Хинт: Оберон-системы не для простых пользователей PC.
    ... << http://dkdens.narod.ru :: http://retroforth.org >>
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 26.01.05 00:17
    Оценка:
    DJ KARIES,

    > ПК>Насколько я понял, в Обероне каждый модуль может быть загружен только один раз. Соответственно, мне кажется, что будут проблемы из разряда того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту возможность у всех остальных пользователей...


    > На атомных станциях не запускают Фотошопов.

    > Ибо дорого.
    >
    > Хинт: Оберон-системы не для простых пользователей PC.

    Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 09:16
    Оценка:
    AVC пишет:

    > В том числе "забывал" присвоить NIL локальному указателю.

    > Затем запускал GC и проверял состояние кучи.
    > Все "безнадежно потерянные", по Вашему убеждению, объекты
    > "подбирались" GC.

    Эххх...
    ==============================
    List list=new ArrayList();
    while(true)
    {
    list.add(new String("Blah-blah"));
    }
    ==============================
    Аналог этого кода на Обероне оставляю в качестве упражнения читателю.

    GC никогда не соберет список, так как он не является мусором.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.01.05 10:49
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH> Надеюсь теперь до тебя дошло что я пытался сказать?


    А при чем тут GC? Или Вы полагаете что его отсутствие вдруг волшебным образом исправит допущенную Вами ошибку?

    С другой стороны, а что если GC отсутствует, в указателе collect_trash_here хранится некое ненулевое значение, и что дальше?

    Вы сделаете:
    1) самостоятельно очистите память и обнулите указатель collect_trash_here (а вдруг его значение кто-то скопировал?)
    2) самостоятельно очистите память и забудете обнулить указатель collect_trash_here (повисшая ссылка)
    3) просто обнулите указатель collect_trash_here забыв освободить память (утечка памяти)
    4) забудете и то и другое

    Все эти пункты являются ошибочными за исключением случая (1) при условии что больше никто не получал информации об collect_trash_here (так как информация становится более недействительной — у кого-то повисает указатель). Все это приводит к краху системы.


    В случае же наличия GC система не падает, а просто ест память, но рано или поздно переменная collect_trash_here все равно может быть обнулена и память будет возвращена, в то время как без GC утекшая память — утекла навсегда.
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 10:49
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>Затем запускал GC и проверял состояние кучи.

    AVC>>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
    Д>Вах-вах, как любопытно. То есть GC взял да и прибил объект, на который остались живые ссылки?

    Вовсе нет!
    WolfHound говорил о стековом указателе (т.к. хотел "зацепить граф объектов за стек".)
    Представим себе какой-нибудь код вроде:
    PROCEDURE SapientiSat;
    VAR p: PointerToVeryBigObject; (* Локальный указатель; находится в стеке *)
    BEGIN
      NEW(p);
      ... (* много полезного кода с этим p :) *)
      (* а здесь я забыл вставить оператор p := NIL *)
    END SapientiSat;

    Видите сами, что указатель p более не существует.
    Т.е. это "мертвая" ссылка.
    По мысли WolfHound, "граф будет жить вечно". (Как Дракула. )
    Но в Обероне все работает правильно.
    Более того, если я все-таки вставляю в конец процедуры злосчастный оператор
    p := NIL

    то некоторые компиляторы Оберона его просто удаляют как излишний, с беззлобными ругательствами вроде:

    eliminatining redundant code

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 10:49
    Оценка:
    Сергей Губанов пишет:

    > C>==============================

    > C>List list=new ArrayList();
    > C>while(true)
    > C>{
    > C> list.add(new String("Blah-blah"));
    > C>}
    > C>==============================
    > C>Аналог этого кода на Обероне оставляю в качестве упражнения читателю.
    > C>GC никогда не соберет список, так как он не является мусором.
    > Вы сделали ошибку под названием "бесконечный цикл". При чем тут GC?
    > Или Вы полагаете, что без него этот код вдруг перестанет содержать
    > ошибку бесконечного цикла?

    И что? С каких это пор бесконечный цикл стал ошибкой?

    > Вот корректный код:

    >
    >PROCEDURE Do (N: INTEGER);
    >VAR list: List; i: INTEGER;
    >BEGIN
    > NEW(list);
    > FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END
    >END Do;
    >
    >
    > Не смотря на то что переменная list располагается на стеке, и, в
    > придачу, при завершении процедуры не производится явного присваивания
    > list := NIL; GC все равно освободит всю память занимаемую списком.

    И пусть N=2^64.

    Будет точно то же самое — утечка памяти до ее полного переполнения.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewJD США  
    Дата: 26.01.05 11:14
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Вот корректный код:

    >>
    >>PROCEDURE Do (N: INTEGER);
    >>VAR list: List; i: INTEGER;
    >>BEGIN
    >> NEW(list);
    >> FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END
    >>END Do;
    >>
    >>

    C>И пусть N=2^64.


    C>Будет точно то же самое — утечка памяти до ее полного переполнения.


    Ммм. А где собственно утечка?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 11:41
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    AVC>>Какой у Вас несчастный опыт борьбы с GC!

    AVC>>Мне Вас искренне жаль!
    WH>А мне вас по скольку вы досихпор не поняли что ГЦ не панацея.

    Конечно, GC — не панацея.
    Я никогда и не утверждал обратного.
    GC — это просто удобный и мощный инструмент.
    Не более, но и не менее.
    В Обероне (не пользуясь низкоуровневыми средствами) "завалить" грамотно написанный GC невозможно. Его нельзя "зацепить" ни за стек, ни за статическую переменную, вопреки Вашему утверждению. (Помните, как странно раньше казалось, что в первоначальном, "виртовском", Паскале указатель мог указывать только на объект в куче. Ан, нет. Вовсе не глупость! Хотя и не получило тогда развития.)
    Конечно, GC отвечает только за определенные свойства системы, а за все отвечать не может.
    "Исчерпание" памяти, например, не является ошибкой GC и не ведет к его "убийству".
    С ним надо бороться другими (системными) средствами: квотами, виртуальной памятью и т.д.

    AVC>>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.

    WH>Значит плохо проверял.
    WH>Пишу на C# думаю на оберон переведешь сам.(не компилил так что могут быть опечатки)
    WH>Левый модуль(заметь никаких "опасных конструкций", ничего не импортирует и тем не мение... )
    WH>
    WH>public class BadClass
    WH>{
    WH>    public BadClass(object o)
    WH>    {
    WH>        CollectTrash(o);
    WH>        CollectTrash(this);
    WH>    }
    WH>    public void BadMethod(object o)
    WH>    {
    WH>        CollectTrash(o);
    WH>    }
    
    WH>    public void ReleaseTrash()
    WH>    {
    WH>        collect_trash_here = null;
    WH>    }
    
    WH>    class List
    WH>    {
    WH>        public object trash;
    WH>        public List next;
    WH>    }
    WH>    static List collect_trash_here = null;
    WH>    void CollectTrash(object o)
    WH>    {
    WH>        List trash = new List();
    WH>        trash.trash = o;
    WH>        trash.next = collect_trash_here;
    WH>        collect_trash_here = trash;
    WH>    }
    WH>}
    WH>

    WH>Надеюсь теперь до тебя дошло что я пытался сказать? Если посоздавать объекты класса BadClass педергать у них метод BadMethod и забыть дернуть ReleaseTrash то мусор будет жить вечно...

    Это уже не является ошибкой GC и не ведет к его падению.
    Я так понял, от идеи "завалить" GC, "зацепив" его за стек, Вы уже отказались.

    WH>Запомни ГЦ всеголишь алгоритм который завалить чуть сложнее чем банальный подсчет сылок. Но можно. Ибо ни один алгоритм не сможет предсказать все ошибки человека. Это не возможно.


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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 26.01.05 12:01
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>По мысли WolfHound, "граф будет жить вечно". (Как Дракула. )

    AVC>Но в Обероне все работает правильно.

    Само собой, что и в CLR тоже — я не думал, что кому-то здесь этот факт неизвестен. Скорее всего, имелась в виду переменная, которая долгое время находится в области видимости (ну например локальная переменная функции-точки входа программы)
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: WolfHound  
    Дата: 26.01.05 12:15
    Оценка:
    Здравствуйте, AVC, Вы писали:

    Вы меня не слышите. Дальнейшие попытки чего либо объяснить предприниматся не будут. Ибо бесполезно.
    Прощайте.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 12:24
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Вы меня не слышите. Дальнейшие попытки чего либо объяснить предприниматся не будут. Ибо бесполезно.

    WH>Прощайте.

    Желаю всего наилучшего!
    (От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 26.01.05 12:38
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Желаю всего наилучшего! :beer:

    AVC>(От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)

    Похоже, обе стороны основательно устали на очередной войне. Можно перейти к дипломатическим методам: выработать общую терминологию (одни и те же вещи в ОС Оберон и Windows называются по-разному), цели создания Оберона, C# или чего там еще, ну и т. д. Только принимая во внимание все факторы, можно вести дискуццию в конструктивном тоне, не опускаясь до примитивного флейма. Тем более, что многие посты / реплики в последней войне выглядат гораздо солиднее и содержательнее как с одной, так и с другой стороны.

    Я тоже извлек для себя пользу из нашего общения. Иначе не заходил бы сюда.
    Счастливо! :beer:
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 12:39
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>По мысли WolfHound, "граф будет жить вечно". (Как Дракула. )

    AVC>>Но в Обероне все работает правильно.
    Д>Само собой, что и в CLR тоже — я не думал, что кому-то здесь этот факт неизвестен. Скорее всего, имелась в виду переменная, которая долгое время находится в области видимости (ну например локальная переменная функции-точки входа программы)

    Я до сих пор не очень понимаю, что именно WolfHound имел в виду.
    Кому "этот факт неизвестен" я тоже не знаю.
    По крайней мере, один из моих предыдущих постов, утверждающий то же самое, Вы лично снабдили отрицательной оценкой.
    Вот этот пост.

    Дело в том, что указатель в Обероне может указывать только на объект, расположенный в куче и не может указывать ни на стековую, ни на статическую переменную.
    Указатель получает свое значение только следующими путями:

    1) NEW(p) — создать новый объект;
    2) p := q; присвоить p значение другого валидного указателя q;
    3) p := NIL; указатель никуда больше не указывает.

    В начале указатель инициализирован NIL.
    Т.е. указатель либо указывает на объект в куче, либо равен NIL.
    И как же нам "зацепить" граф объектов за стек или статические переменные?

    Я так и не понял тогда, в каком именно пункте Вы со мной не согласны.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 12:49
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    P>Похоже, обе стороны основательно устали на очередной войне. Можно перейти к дипломатическим методам: выработать общую терминологию (одни и те же вещи в ОС Оберон и Windows называются по-разному), цели создания Оберона, C# или чего там еще, ну и т. д. Только принимая во внимание все факторы, можно вести дискуццию в конструктивном тоне, не опускаясь до примитивного флейма. Тем более, что многие посты / реплики в последней войне выглядат гораздо солиднее и содержательнее как с одной, так и с другой стороны.


    P>Я тоже извлек для себя пользу из нашего общения. Иначе не заходил бы сюда.

    P>Счастливо!

    Согласен!
    Надо наконец-то перейти к более конструктивному обсуждению.
    Как следствие, вероятно, постов станет меньше, но они будут содержательнее и продуманнее, и не будут носить "личного" характера.
    Значит, пользы будет больше.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 26.01.05 12:57
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Желаю всего наилучшего!

    AVC>(От себя могу добавить, что я все-таки извлек для себя некоторую пользу из нашего общения. За это — спасибо!)

    WolfHound хотел сказать (если я правильно понял ), что разница между тем, забудем ли мы вызвать для неуправляемого указателя оператор delete, или забудем присвоить nil долгоживущему управляемому указателю в системе с ГЦ не принципиальна. В любом случае, память, которую можно было бы использовать для текущей задачи будет недоступна, и, следовательно, мы имеем утечку.

    Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 26.01.05 13:14
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>И как же нам "зацепить" граф объектов за стек или статические переменные?


    "зацепить" в данном случае — это присвоить ссылку на граф стековой или статической переменной.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 13:24
    Оценка:
    Здравствуйте, prVovik, Вы писали:

    V>WolfHound хотел сказать (если я правильно понял ), что разница между тем, забудем ли мы вызвать для неуправляемого указателя оператор delete, или забудем присвоить nil долгоживущему управляемому указателю в системе с ГЦ не принципиальна. В любом случае, память, которую можно было бы использовать для текущей задачи будет недоступна, и, следовательно, мы имеем утечку.

    V>Но в OberonOS, насколько я понял, мы не можем, как в традиционных ОС, убить "обнаглевший" процесс и гарантированно освободить его ресурсы.

    По крайней мере, это — разумная мысль.
    Если бы в ОС Оберон мы не могли "убить" "нашкодивший" процесс, то занятые им ресурсы не могли бы вернуться в систему.
    Но, слава Богу, это не так. В Обероне можно "убить" процесс.
    А иначе к чему бы привело возниковение первого же исключения в системе? (Скажем, при делении на ноль.)
    Если такой процесс сам не перехватывает исключения, то за него это делает система. После чего данный конкретный процесс ликвидируется, ресурсы освобождаются, а система продолжает работать.
    (Ядро же вообще неуязвимо, т.к. все его объекты либо недоступны снаружи (не экспортируются модулями ядра), либо доступны без возможности их изменения (экспортируются скрыто).)
    Другая ситуация: бесконечный цикл.
    LOOP END;

    Эта ситуация кажется опасной для вариаций первоначальной ETH Oberon, потому что в ней многозадачность реализуется на базе единственного процесса.
    Я проделывал такой эксперимент: писал модуль, содержащий команду с бесконечным циклом, и пытался "подвесить" систему. При нажатии Ctrl-Break (вместо вызова Task Manager'а в Windows) поток этой команды убивался, система работала, ресурсы возвращались (т.к. Ctrl-Break вызывала исключение.)
    Не блестяще, конечно, но первоначальная версия ETH Oberon предназначалась для однопользовательской рабочей станции. Так что такое поведение вполне было приемлимо. (Windows в те годы преспокойно зависала.)
    И надо помнить, что сейчас существует варианты Оберона с "настоящей" многозадачностью.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 13:58
    Оценка:
    AndrewJD пишет:

    >>> Вот корректный код:

    >>>PROCEDURE Do (N: INTEGER);
    >>>VAR list: List; i: INTEGER;
    >>>BEGIN
    >>> NEW(list);
    >>> FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END
    >>>END Do;
    >>>
    >>>
    > C>И пусть N=2^64.
    > C>Будет точно то же самое — утечка памяти до ее полного переполнения.
    > Ммм. А где собственно утечка?

    Мы имеем семантический мусор в переменной list — ее содержимое никогда
    не будет использовано, но существующие ссылки не дают этот мусор удалить.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 14:01
    Оценка:
    Дарней пишет:

    > Если я не ошибаюсь, именно это долго и безуспешно пытаются донести до

    > фанатов Оберона другие участники дискуссии.

    Именно.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 26.01.05 14:20
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    Д>Если я не ошибаюсь, именно это долго и безуспешно пытаются донести до фанатов Оберона другие участники дискуссии.


    Это, IMHO, действительно, центральный вопрос.
    Собственно говоря, единственный.
    Остальные претензии к Оберону, скорее, надуманы. Их, почему-то, больше всего и "мусолят".
    Но почему же "долго и безуспешно"?
    См. например:
    http://www.rsdn.ru/Forum/Message.aspx?mid=1001716&amp;only=1
    Автор: AVC
    Дата: 24.01.05

    Опять же Вы лично выражали несогласие с моей точкой зрения. Запамятовали?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.01.05 14:41
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C> И что? С каких это пор бесконечный цикл стал ошибкой?


    Бесконечный цикл в котором выделяется память и назад никогда не отдается безусловно является ошибкой, просто согласно здравому смыслу — объем памяти конечен, следовательно рано или позндно вся память будет исчерпана.

    Кстати, при чем тут наличие или отсутсвие GC Вы так и не объяснили.
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 26.01.05 14:59
    Оценка:
    Hello, Сергей!
    You wrote on Wed, 26 Jan 2005 14:41:58 GMT:

    СГ> Бесконечный цикл в котором выделяется память и назад никогда не

    СГ> отдается безусловно является ошибкой, просто согласно здравому смыслу -
    СГ> объем памяти конечен, следовательно рано или позндно вся память будет
    СГ> исчерпана.

    Кстати, пусть это будет ошибкой. Ну что с ней дальше делать — всю систему
    ронять?

    СГ> Кстати, при чем тут наличие или отсутсвие GC Вы так и не объяснили.


    Не знаю, что имел в виду Cyberax, но лично мне, например, непонятно, что
    должен делать в таком случае GC (или кто там будет освобождать память при
    убиении ошибочного модуля), при условии, что, как вы ранее заявляли, "... то
    необходимость в создании множества виртуальных адресных пространств (для
    безопасности) больше не существует — достаточно одного единого на всю
    систему адресного пространства, а безопасность гарантируется языком
    программирования, рантайм проверками индексов массивов, контролем приведения
    типов."
    В случае раздельных адресных пространств все просто — отстреливаем дохлую
    задачу и освобождаем всю принадлежащую ей память. Что делать в случае
    единого адресного пространства, когда вся надежда только на GC?

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 26.01.05 15:11
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>В случае раздельных адресных пространств все просто — отстреливаем дохлую

    S>задачу и освобождаем всю принадлежащую ей память. Что делать в случае
    S>единого адресного пространства, когда вся надежда только на GC?

    Вот ума не приложу — какая разница сколько у Вас адресных пространств?
    Убей более не нужный объект — память освободиться сама (за счет того самого GC).
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewJD США  
    Дата: 26.01.05 16:58
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Мы имеем семантический мусор в переменной list — ее содержимое никогда

    C>не будет использовано, но существующие ссылки не дают этот мусор удалить.

    Это уже проблема оптимизатора, который не удалил код который ничего не делает. После выхода из блока(в данном случае функции) все почистится. Где утечка?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 17:05
    Оценка:
    AndrewJD пишет:

    > C>Мы имеем семантический мусор в переменной list — ее содержимое никогда

    > C>не будет использовано, но существующие ссылки не дают этот мусор
    > удалить.
    > Это уже проблема оптимизатора, который не удалил код который ничего не
    > делает.

    Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ
    программы. В данном куске кода все сразу видно, но в реальности все
    может быть намного сложнее.

    > После выхода из блока(в данном случае функции) все почистится. Где

    > утечка?

    А мы НИКОГДА не выходим из блока. Можно сделать переменную list
    статической — результат будет ровно тем же.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[48]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewJD США  
    Дата: 26.01.05 17:31
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ

    C>программы. В данном куске кода все сразу видно, но в реальности все
    C>может быть намного сложнее.

    Только причем здесь GC?
    Чем этот код принципиально отличается от

    
    char* p = new char[2000000000];
    
    //здесь что-то делаем
    
    delete[] p;



    C>А мы НИКОГДА не выходим из блока. Можно сделать переменную list

    C>статической — результат будет ровно тем же.

    Все равно ничего не понимаю .
    Ровно с таким же успехом мы могли попытаться поднять в память 4 гигабайтный xml и попытаться распарсить его в DOM.
    Т.е. это будет не мусор, а 8 гиг полезных данных.
    Какое это отношение имеет к защите памяти, GC, и раздельным адресным пространствам?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[49]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 26.01.05 17:37
    Оценка:
    AndrewJD пишет:

    > C>Никакой оптимизатор тут не спасет, так как нужно анализировать ЛОГИКУ

    > C>программы. В данном куске кода все сразу видно, но в реальности все
    > C>может быть намного сложнее.
    > Только причем здесь GC?
    > Чем этот код принципиально отличается от
    >
    >char* p = new char[2000000000];
    >
    >//здесь что-то делаем
    >
    >delete[] p;
    >
    >
    Принципиально ничем не отличается.

    > C>А мы НИКОГДА не выходим из блока. Можно сделать переменную list

    > C>статической — результат будет ровно тем же.
    > Все равно ничего не понимаю .
    > Ровно с таким же успехом мы могли попытаться поднять в память 4
    > гигабайтный xml и попытаться распарсить его в DOM.
    > Т.е. это будет не мусор, а 8 гиг полезных данных.
    > Какое это отношение имеет к защите памяти, GC, и раздельным адресным
    > пространствам?

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Шахтер Интернет  
    Дата: 27.01.05 02:01
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Дарней, Вы писали:


    AVC>>>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".

    Д>>Запорожец-лимузин тоже существует. Только это не доказывает, что он годится хоть для какого-то практического использования.
    Д>>И вопрос звучит не "КАК это работает", а "где гарантия, что это будет работать НЕ в лабораторных условиях"

    AVC>Работает же.

    AVC>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.
    AVC>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.

    Ну может быть, всё же не надо дезинформировать общественность. На Марс летал vxWorks, написанный на C.

    AVC>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.


    Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.
    ... << RSDN@Home 1.1.0 stable >>
    В XXI век с CCore.
    Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
    Re[48]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 27.01.05 04:54
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Опять же Вы лично выражали несогласие с моей точкой зрения. Запамятовали?


    Ну про это я уже высказывался.
    Позволю себе процитировать:

    На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".

    Напомню еще раз — вопрос был только один: "А достаточно ли надежно это работает"? Пока что ответ был "нет, недостаточно", и никаких заслуживающих внимания аргументов против него приведено не было.
    Все "зверски крутые" случаи с применением Оберона, которые тут приводились — это стерильно-лабораторные случаи, когда каждая программа тщательно проверяется и тестируется перед ее выполнением. В обычной жизни такого не будет

    Должен признать, что и наши аргументы иногда неубедительны.
    Я думаю, все это по причине плохой информированности.

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

    Как я опять же говорил — ОберонОС не конкурент Windows или Linux, и никогда не будет — кишка тонка. Под SymbianOS тоже веб-серверы есть. Вот только ни один фанатик не ставит ее в один разряд с серверными ОС, или хотя бы десктопными.
    Так что ОберонОС так и останется нишевой ОС — в лучшем для нее случае.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[51]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 27.01.05 06:03
    Оценка:
    Здравствуйте, Трурль, Вы писали:

    Т>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?


    Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 27.01.05 09:23
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Ладно, попробую объяснить еще раз. Вот в Юниксе (да и в Винде) есть

    C>дерево процессов, каждый процесс независим от другого (если не
    C>используются специальные механизмы IPC). Если мы прибиваем один процесс
    C>или дерево — это не влияет на остальные процессы.
    Я, наконец понял, что имеется в виду. Это заняло приличное время, но я справился .

    Ты думаешь, что если задачи (ну.. модули) выполняются реально в одном процессе, то у них общая память в смысле прямых указателей на объекты друг друга, да? Это не так.

    Я тут щас не собираюсь защищать ОберонОС, но меня сильно смущает, что ты и WolfHound так прете против самих принципов. Софтварная изоляция — это круто, за ней будущее. По возможностям нет принципиальной разницы между хардварной и софтварной изоляции. По скорости софтварная быстрее, да да, и жрет меньше русурсов. Это понятно само по себе, и даже не нужно никаких тестов.

    Вот подумай сам: в STL рассмотрена целая куча возможных ситуаций, до самых мелочей. "С копирующим конструктором и без", "простой класс объектов и сложный", "где лежит контейнер". А теперь предлагаешь, чтобы в Обероне, как "в убогой университетской поделке с устаревшим синтаксисом того еще Паскаля", всё было сделано в лоб: один процесс на ОС и на задачи, без многозадачности, с прямыми указателями на объекты ядра и драйверами на C++? Хи-хи получается .
    Re[50]: А если подумать?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 09:29
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>В обычных ОСах система может просто прибить процесс, который эту ситуацию

    C>вызвал (у всех процессов — разные адресные пространства), но в ОберонОС
    C>этого сделать нельзя — так как нельзя автоматически определить какие
    C>объекты являются мусорными. Прибивать произвольные объекты тоже нельзя —
    C>нарушится ссылочная целостность.

    А если подумать?

    1) ГЦ (по определению) знает весь граф связей между объектами (в каждый момент времени).
    2) Решение о прибивании неугодного объекта принимает либо система, либо пользователь, но не ГЦ (он тут не причем).
    3) После того как принято решение об убивании неугодного объекта, благодаря доступной ГЦ информации о графе связей объектов, можно найти связную компоненту графа внутри которой находится неугодный объект.
    4) Уничтожению подлежит именно эта компонента связности графа объектов — забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач перестает выделять процессорное время для активных объектов принадлежащей этой компоненте связности.
    5) Как только мы о ней "забыли", ГЦ ее уничтожил. И дело с концом.

    Таким образом, для убивания неугодных объектов совершенно не важно сколько адресных пространств.
    Re[51]: А если подумать?
    От: Sergey Россия  
    Дата: 27.01.05 09:52
    Оценка:
    Hello, Сергей!
    You wrote on Thu, 27 Jan 2005 09:29:23 GMT:

    СГ> 1) ГЦ (по определению) знает весь граф связей между объектами (в каждый

    СГ> момент времени). 2) Решение о прибивании неугодного объекта принимает
    СГ> либо система, либо пользователь, но не ГЦ (он тут не причем). 3) После
    СГ> того как принято решение об убивании неугодного объекта, благодаря
    СГ> доступной ГЦ информации о графе связей объектов, можно найти связную
    СГ> компоненту графа внутри которой находится неугодный объект. 4)
    СГ> Уничтожению подлежит именно эта компонента связности графа объектов -
    СГ> забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач
    СГ> перестает выделять процессорное время для активных объектов
    СГ> принадлежащей этой компоненте связности. 5) Как только мы о ней
    СГ> "забыли", ГЦ ее уничтожил. И дело с концом.

    Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро
    прибиваем нафиг? Здорово.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 27.01.05 09:54
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...

    Да, я тоже за это. И слабо понимаю, как можно быть против .
    Хардварная изоляция нужна для одного: поддерживать старые проги (чтобы играть в Doom2 ).
    Re[52]: А если подумать?
    От: Privalov  
    Дата: 27.01.05 09:57
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро

    S>прибиваем нафиг? Здорово.

    S>With best regards, Sergey.


    Не думаю. Сейчас нам расскажут, что нет там никаких Callback.
    Если поискать как следует, то можно найти прецеденты: нет памяти, нет процессов, и т. д. Сползаем (в который раз!) на уровень обсуждения сферических коней в вакууме...
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 27.01.05 10:09
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>

    СГ>"Рука устала"

    СГ>Начать отсюда:

    СГ>http://www.inr.ac.ru/~info21/


    СГ>далее по всем ссылкам...


    Я б с огромным удовольствием, дак большинство ссылок — мертвые.
    Re[52]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 11:18
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    Т>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?

    P>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[51]: А если подумать?
    От: Дарней Россия  
    Дата: 27.01.05 11:19
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Таким образом, для убивания неугодных объектов совершенно не важно сколько адресных пространств.


    И все-таки, что случится со ссылками на убитый объект?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 11:32
    Оценка:
    Здравствуйте, Шахтер, Вы писали:

    AVC>>Работает же.

    AVC>>Честно говоря, "рука уже устала" писать одно и то же: Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока.
    AVC>>Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.

    Ш>Ну может быть, всё же не надо дезинформировать общественность. На Марс летал vxWorks, написанный на C.


    (С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не дезинформировать общественность.
    Действительно, некоторые страны (мне известно о Канаде и UK) ограничивают применение Си/Си++ в критических областях, прежде всего в области ПО для атомной энергетики.

    AVC>>В принципе, Си++ — язык для детской песочницы. Персоналки, "поставщик кода отвтетственности не несет" и т.п.

    Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и сложные проекты.

    И какие из них САМЫЕ КРУПНЫЕ?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[53]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 27.01.05 11:41
    Оценка:
    Hello, AVC!
    You wrote on Thu, 27 Jan 2005 11:18:09 GMT:

    A> А чем в этом отношении Оберон хуже?

    A> В Обероне "плохой" процесс убивается, в Log выводится trap text.

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

    A> В данном пункте не вижу разницы.

    A> А вопрос Трурль задал правильный.
    A> Противники Оберона постоянно высказываются в том духе, что "убийство
    A> процесса" есть главный (чуть ли не единственный) механизм безопасности в
    A> ОС. Вот Трурль и задает простой вопрос: как процесс становится "плохим",
    A> когда его пора убивать?

    Например, если юзер захотел — типа adware какое-нибудь обнаружил. Данное
    adware успело зарегистрировать коллбэки на все, на что смогло. Как его
    срубить, если GC при этом потянит за одной задачей полсистемы?

    A> У меня есть некоторое опасение, что в полном объеме эта задача

    A> может оказаться и алгоритмически неразрешимой.

    Что с того? Частные случаи, когда необходимо уметь прибить процесс в любом
    случае достаточно важны.

    A> Кроме того, такие большие

    A> надежды на отдельные адресные пространства в чем-то разумны, а в чем-то
    A> немного наивны.

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

    A> Видимо, следует полагать, что "плохой" процесс либо

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

    Влияет, конечно. Но в системах с разделением адресных пространств задачи
    устроены так, что это влияние в большинстве случаев не является
    катастрофическим. Потому что на GC и безопасные языки программирования никто
    не надеется и напрямую в память других процессов не лазит. Ну и помимо
    разных адресных пространств в "нормальных" операционках еще куча барьеров и
    рогаток предусмотрена.
    Например, упал екзешник посреди EnumChildWindows — однако подсистеме user
    ничего плохого не делается. Очевидно, что один GC в такую ситуацию не сможет
    разрешить, необходимы другие механизмы. Однако некоторые почему-то
    утверждают обратное.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 12:21
    Оценка:
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Ну и почти по теме ветки (чтоб совсем в оффтоп не скатываться): хотел выразить свой респект господину AVC (даже несмотря на то, что он меня слегка обгадил )


    Чувствую себя немного свиньей...
    Но, по замыслу, это был не личный выпад, конечно.
    Просто хотел обратить внимание общественности, что Си++ "разрешено" и "просто так" любить, а Оберон — почему-то нельзя, даже если у этого языка (и у одноименной системы тоже) есть свои достоинства.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 12:45
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    A>> А чем в этом отношении Оберон хуже?

    A>> В Обероне "плохой" процесс убивается, в Log выводится trap text.
    S>Вопрос уже задавали — что происходит с другими процессами, в которых есть
    S>указатели, ссылающиеся на данные в этом процессе.

    Вы, наверное, имеете в виду статические указатели, разделяемые между разными процессами. (В отношении стековых указателей мы уже выяснили, что ничего страшного произойти не должно.)
    Здесь и правда есть проблема.
    Но она опять же несколько сложнее, чем видится критикам.
    Откуда уверенность, что, если процесс сделал что-то "плохое", то и все установленные им статические указатели тоже "плохие"?
    А если они — "хорошие"? Если они очень нужны для корректной работы остальных процессов?
    Как отделить, так сказать, "овец от козлищ"?
    "Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я в ней сомневаюсь. )
    Хочу особенно обратить Ваше внимание, что нам (гадким сторонникам Оберона, бякам-букам и т.п.) было бы очень легко угодить взыскательному вкусу критиков.
    Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.)
    И никаких проблем со статическими указателями!
    Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей в Обероне — ациклическая.
    Не потребуется даже менять текст программ.
    Просто настроить динамический загрузчик: грузи модули ядра один раз, а остальные — по одному на каждое импортирующее его приложение.
    Если такое приложение выгрузить, то все его модули могут быть выгружены тоже.
    При этом Оберон по-прежнему остается быстрее Линукса и т.д., т.к. адресное пространство остается единым. (Просто переменные одного процесса недоступны переменным другого.)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 12:50
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Sergey, Вы писали:


    A>>> А чем в этом отношении Оберон хуже?

    A>>> В Обероне "плохой" процесс убивается, в Log выводится trap text.
    S>>Вопрос уже задавали — что происходит с другими процессами, в которых есть
    S>>указатели, ссылающиеся на данные в этом процессе.

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

    Я так и не понял что такое "статические указатели", если указатели, являющиеся стат. переменными, то непонятно, как же решилась проблема со обычными стековыми переменными? Если есть переменная в другом процессе в стеке, что с ней будет? Никакого объяснения я что-то не припомню...
    Поясните, может я чего не заметил за всей этой перепалкой.
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 27.01.05 13:08
    Оценка:
    Hello, AVC!
    You wrote on Thu, 27 Jan 2005 12:45:48 GMT:

    A>>> А чем в этом отношении Оберон хуже?

    A>>> В Обероне "плохой" процесс убивается, в Log выводится trap text.
    S>> Вопрос уже задавали — что происходит с другими процессами, в которых
    S>> есть указатели, ссылающиеся на данные в этом процессе.

    A> Вы, наверное, имеете в виду статические указатели, разделяемые между

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

    Она, вдобавок, несколько сложнее, чем видится некоторым защитникам

    A> Откуда уверенность, что, если процесс сделал что-то "плохое", то и

    A> все установленные им статические указатели тоже "плохие"?

    Это ты Губанова спрашивай — он говорил, что модуль выгружать будем. Заодно и
    все модули, на которые GC укажет.

    A> А если они — "хорошие"? Если они очень нужны для корректной работы

    A> остальных процессов?

    Вот и я о том же — что, если они очень нужны для корректной работы остальных
    процессов?

    A> Как отделить, так сказать, "овец от козлищ"?

    Вот пока защатники Оберона этого не показали.

    A> "Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я

    A> в ней сомневаюсь. )

    Аналогично.

    A> Хочу особенно обратить Ваше внимание, что нам (гадким сторонникам

    A> Оберона, бякам-букам и т.п.) было бы очень легко угодить взыскательному
    A> вкусу критиков. Достаточно было бы разрешить повторно грузиться всем
    A> модулям, кроме модулей ядра
    (т.к. ядро — одно на всех.) И никаких
    A> проблем со статическими указателями!

    Зато появляется куча других проблем.

    A> Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей

    A> в Обероне — ациклическая.

    Т.е., коллбэков и подобного нет в принципе?

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 13:17
    Оценка:
    Здравствуйте, Курилка, Вы писали:

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

    К>Я так и не понял что такое "статические указатели", если указатели, являющиеся стат. переменными, то непонятно, как же решилась проблема со обычными стековыми переменными? Если есть переменная в другом процессе в стеке, что с ней будет? Никакого объяснения я что-то не припомню...
    К>Поясните, может я чего не заметил за всей этой перепалкой.

    "Статические" (в смысле Си) указатели — это указатели, являющиеся переменными какого-нибудь модуля, а не стековыми переменными.
    Т.е. именно то, что Вы и предположили.
    Теперь о стековых указателях.
    Стековый указатель "сбрасывается" при выходе из соответствующей процедуры, или при обработке исключения.
    Насколько я догадываюсь, это может быть задачей эпилога процедуры.
    Т.е. при выходе из процедуры, нормальном завершении или "убийстве" процесса по исключению, все стековые указатели становятся недействительными и не представляют проблемы для GC.
    Другое дело — статические указатели.
    Т.к. модуль может обслуживать несколько процессов (потоков, в терминологии Windows), то указатель не "умирает" вместе с процессом.
    Этот факт и является "яблоком раздора".
    Как я уже писал, эта проблема легко (IMHO, конечно ) решается разрешением повторной загрузки (и последующей выгрузки) прикладных модулей.
    К тому же, это очень удобно для разработчиков: перекомпилировал модуль, и он сразу готов для употребления. Причем сразу всеми приложениями. Ведь в Обероне, как и в Смоллтоке, статическая линковка необязательна.
    Но при этом растет объем требуемой оперативной памяти и затрудняется межпроцессное взаимодействие. (Т.е. происходит примерно то же, что в "нормальных", как кто-то тут сказал, ОС.)
    Информации по тонкостям современных многозадачных Оберон-систем у нас недостаточно.
    Вот мы и стараемся ее "нарыть", в промежутках между основной работой. Ищем "доки", проводим эксперименты и т.д.
    Иногда пытаемся предложить свое (м.б., наивное ) решение.
    И только если будет доказано, что наши поиски бесполезны, вернемся к указанному "безопасному" варианту.
    Т.е. находимся в поиске .

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 13:22
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    A>> Но она опять же несколько сложнее, чем видится критикам.

    S>Она, вдобавок, несколько сложнее, чем видится некоторым защитникам



    A>> Как отделить, так сказать, "овец от козлищ"?

    S>Вот пока защатники Оберона этого не показали.

    Никто этого пока здесь не показал.
    Вопрос Трурля так и повис в воздухе.

    A>> "Прибить все указатели" — сомнительная рекомендация. (По крайней мере, я

    A>> в ней сомневаюсь. )
    S>Аналогично.



    S>Зато появляется куча других проблем.


    Наверное. А каких именно?

    A>> Тем более, все это очень хорошо "вяжется" с тем, что зависимость модулей

    A>> в Обероне — ациклическая.
    S>Т.е., коллбэков и подобного нет в принципе?

    А вот здесь связи нет.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 27.01.05 13:52
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    AVC>>Достаточно было бы разрешить повторно грузиться всем модулям, кроме модулей ядра (т.к. ядро — одно на всех.)

    СГ>Ересь какая...
    СГ>Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон. Для "множественности" придумано ООП. Создаете столько объектов сколько хочется и работаете с этим множеством контекстов. А модуль — это всего лишь вместилище кода, который сам по себе "не обладает свободой воли".

    Я просто обозначил "предельную черту".
    Если мы переступим ее, то предшествующая критика Оберона потеряет силу.
    А выгоды, тем не менее, останутся!
    Например, системный вызов останется таким же быстрым.
    Значит, Оберон-система — уже не глупость.
    Т.е. я хотел показать критикам тот максимум, которого они могут достигнуть.
    (В отношении же языка Оберон, вся критика уперлась в отсутствие шаблонов. У Windows-приложения на Обероне нет никаких "проблем со статическими указателями", т.к. это приложение — отдельный процесс в смысле Windows.)

    AVC>> И никаких проблем со статическими указателями!

    СГ>А проблем и так нет.

    Ну, попутали меня бесы!
    С точки зрения критиков — они есть.
    Они верят: если процесс убить — станет хорошо.
    А если два процесса — еще лучше, наверное.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[51]: А если подумать?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 27.01.05 14:00
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:
    СГ>А если подумать?

    СГ>1) ГЦ (по определению) знает весь граф связей между объектами (в каждый момент времени).

    СГ>2) Решение о прибивании неугодного объекта принимает либо система, либо пользователь, но не ГЦ (он тут не причем).
    СГ>3) После того как принято решение об убивании неугодного объекта, благодаря доступной ГЦ информации о графе связей объектов, можно найти связную компоненту графа внутри которой находится неугодный объект.
    СГ>4) Уничтожению подлежит именно эта компонента связности графа объектов — забываем о ней: а) обнуляем корневые ссылки, б) планировщик задач перестает выделять процессорное время для активных объектов принадлежащей этой компоненте связности.
    СГ>5) Как только мы о ней "забыли", ГЦ ее уничтожил. И дело с концом.

    СГ>Таким образом, для убивания неугодных объектов совершенно не важно сколько адресных пространств.

    Нда. Наукообразно, но бессмысленно.
    1. Что делать, если эта компонента связности включает в себя популярные объекты — типа Screen, Printer, Disk? Что останется в памяти после убийства всех этих компонент?
    2. Что такое "обнуление корневых ссылок"? Вот у меня есть объект А. К примеру, это DeskTop. Я передаю ему ссылку на свое окно, поскольку именно десктоп берет на себя управление окнами. Вот меня надо убить. Ясно, что мое окно входит в компоненту связности — у меня есть ссылка на него, да и окно ссылается на своего автора. Угу. А DeskTop ссылается на окно. Какую из ссылок ты будешь обнулять?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Денис Федин Россия  
    Дата: 27.01.05 14:04
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Вот забавно-то, проект значит крупный и сложный, а выполняется он на Си только из-за того что для выбранной платформы компилятора другого может не оказаться! Курам на смех! Да это значит вовсе никакой не крупный проект, а так рядовая коммерческая работа.


    В моем понимании крупный и сложный проект это разработка "с нуля" ОС, СУБД, OpenGL и т.д.
    Наверное это в вашем понимании рядовая коммерческая работа.

    СГ>Вот по настоящему крупный и сложный проект — это когда есть новое голое железо, под которое надо написать все — и новую операционку, и новый компилятор нового языка (на самом себе), и прикладные программы. Именно в результате такой работы на свет появилась ОС Оберон и язык программирования Оберон. Именно поэтому они такие какие есть — все необходимое и достаточное в них есть, а лишних погремушек нет.


    В свое время такое говорили про Форт-систему.
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 27.01.05 14:17
    Оценка:
    Hello, AVC!
    You wrote on Thu, 27 Jan 2005 13:22:24 GMT:

    A> Никто этого пока здесь не показал.

    A> Вопрос Трурля так и повис в воздухе.

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

    S>> Зато появляется куча других проблем.


    A> Наверное. А каких именно?


    В первую очередь — восстановление состояния. В общем случае задача, IMHO, не
    решается. Значит, в каждом частном случае заниматься этим придется
    разработчику модуля. А это ни к чему хорошему не приведет.

    A>>> Тем более, все это очень хорошо "вяжется" с тем, что зависимость

    A>>> модулей в Обероне — ациклическая.
    S>> Т.е., коллбэков и подобного нет в принципе?

    A> А вот здесь связи нет.


    Почему это нет? Я уже приводил пример — некий модуль начал выполнять что-то
    вроде EnumChildWindows, во время которого его убили. Если следовать
    рекомендациям Губанова, следует заодно убить с помощью GC все модули,
    которые ссылаются на дефектный модуль. Т.е., убиваем модуль user или что там
    вместо него у нас будет. А потом, возможно, пытаемся загрузить его снова —
    только все открытые окошки при этом тю-тю (это к вопросу о восстановлении
    состояния).

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[53]: А если подумать?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 14:31
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Sergey, Вы писали:


    S>>Т.е., если дефектный объект поставил свои коллбэки куда-нибудь в ядро, ядро

    S>>прибиваем нафиг?

    СГ>А что, страшно, да?


    СГ>Подумаешь, перезапустим пару-тройку системных объектов...


    СГ>Ну, давайте, вытаращивайте глаза еще шире, крутите пальцем у виска и кричите: "Этого не может быть потому что этого не может быть никогда!"



    Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом движении надо было тачку перезагружать
    Это кайф
    Re[52]: А если подумать?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 14:36
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S> К примеру, это DeskTop. Я передаю ему ссылку на свое окно, поскольку именно десктоп берет на себя управление окнами. Вот меня надо убить. Ясно, что мое окно входит в компоненту связности — у меня есть ссылка на него, да и окно ссылается на своего автора. Угу. А DeskTop ссылается на окно. Какую из ссылок ты будешь обнулять?


    А что если я отвечу на этот вопрос? Вы свою шляпу обещаете съесть?
    Re[54]: А если подумать?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 14:42
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом движении надо было тачку перезагружать


    А) С какой стати?
    Б) Где вы углядели перезапуск тачки?
    Re[53]: А если подумать?
    От: prVovik Россия  
    Дата: 27.01.05 15:15
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Рантайм система не видит разницы между объектами операционки и объектами приложений.

    Хм, и о какой надежности после этого можно говорить?

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

    Кольца защиты, кстати, придумали не от нечего делать ...
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[54]: Перейдем от слов к делу?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 15:23
    Оценка:
    Здравствуйте, prVovik, Вы писали:

    V>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Рантайм система не видит разницы между объектами операционки и объектами приложений.

    V>Хм, и о какой надежности после этого можно говорить?

    V>Получается, что из-за ошибки в некоторой задаче может быть прибита другая абсолютно независимая задача из-за транзитивной связи от ядра к "плохой" задаче и от "хорошей" к ядру?


    V>Кольца защиты, кстати, придумали не от нечего делать ...


    Предлагаю перейти от слов к делу. Установите какой-нибудь оберон и попробуйте его уронить.


    Эксперимент:
    http://www.rsdn.ru/Forum/Message.aspx?mid=1008117&amp;only=1
    Автор: Сергей Губанов
    Дата: 27.01.05
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 27.01.05 15:25
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:
    СГ>Каким макаром вдруг адресные пространства связаны с владельцами ресурсов?
    А очень простым. Каждый указатель живет в некотором адресном пространстве. В принципе невозможно ссылаться на объект, живущий в одном адресном пространстве, из другого. Поэтому мы всегда можем ткнуть пальцем в хозяина каждого объекта. Ну вот к примеру открытый файл. В винде у процесса есть handle для этого файла. Этот handle имеет смысл только в адресном пространстве соответствующего процесса, и "отдать" его в другой процесс нельзя. Задачи типа "передать ссылку на открытый файл" решаются при помощи весьма специфического маршалинга (DuplicateHandle). Это приводит, в частности, к тому, что система умеет корректно очищать ресурсы при завершении процесса. Еще вопросы?

    СГ>Вот именно, что это он обладает ссылкой на нее, а не она обладает ссылко на него. Он ей безразличен. Компонента связности в точности равна аналогичному понятию ПРОЦЕССА в Windows/UNIX. Как Windows/UNIX процессы не знают друг о друге, так же и тут, одна компонента связности графа объектов не знает о других.

    Ок, давай тогда в студию определение "компоненты связности". Я-то дурень полагал, что ты используешь обычное определение из теории графов.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[54]: Эксперимент
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 15:28
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Ну, что, съели? Еще возникать будете? Может еще какой-нибудь эксперимент поставим?


    Товарищи модераторы, за такое банить надо, однако
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 15:54
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, Сергей Губанов, Вы писали:

    СГ>>Каким макаром вдруг адресные пространства связаны с владельцами ресурсов?

    S>А очень простым. Каждый указатель живет в некотором адресном пространстве. В принципе невозможно ссылаться на объект, живущий в одном адресном пространстве, из другого. Поэтому мы всегда можем ткнуть пальцем в хозяина каждого объекта.


    Пальцем Вы тыкаете не на хозяина, а на все адресное пространство вместе взятое и удаляете его целиком в случае чего. Тем не менее, в случае safe системы, хозяина можно вычислить совершенно точно — ведь информация о связях между объектами известна. Поэтому убивать можно не все пространство, а лишь того кто провинился, а раз так, то множественность адресных пространств — всего лишь излишняя обуза.


    СГ>>Вот именно, что это он обладает ссылкой на нее, а не она обладает ссылко на него. Он ей безразличен. Компонента связности в точности равна аналогичному понятию ПРОЦЕССА в Windows/UNIX. Как Windows/UNIX процессы не знают друг о друге, так же и тут, одна компонента связности графа объектов не знает о других.


    S>Ок, давай тогда в студию определение "компоненты связности". Я-то дурень полагал, что ты используешь обычное определение из теории графов.


    Не валяете дурака. Если объект знает обо мне, но я о нем не знаю, то удалить его можно не удаляя меня.
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 27.01.05 15:58
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Не валяете дурака. Если объект знает обо мне, но я о нем не знаю, то удалить его можно не удаляя меня.


    Ага, а как же пример с десктопом — он знает об окне, но десктоп не удаляется...
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 27.01.05 16:02
    Оценка:
    Здравствуйте, prVovik, Вы писали:

    V> Короче, ГЦ и СРВ — это вещи несовместимые.


    Не используйте. Язык это допускает (выделил жирным шрифтом):

    Приложение D: Обязательные требования к среде выполнения
    Определение Компонентного Паскаля опирается на три фундаментальных предположения.

    1) Во время исполнения программ доступна информация, позволяющая проверять динамический тип объекта. Это нужно для реализации проверок типов и охраны типов.

    2) Отсутствует процедура DISPOSE <освобождение памяти под более не используемые объекты>. Память <занимаемая объектом> не может быть освобождена по явной инструкции программиста, поскольку это создало бы проблемы безопасности, связанные с потерей памяти [memory leaks] <память, занимаемая объектами, недоступными ни через какие указатели, которую программист забыл освободить> и с висячими указателями [dangling pointers] <доступные указатели, продолжающие указывать на области памяти, по ошибке преждевременно освобожденные>. За исключением таких встроенных систем, где не используется динамическое управление памятью, или где ее можно разместить только однажды и никогда не нужно освобождать, требуется автоматический сбор мусора.

    3) Модули и по крайней мере их экспортированные процедуры (команды) и экспортированные типы должны быть доступны динамически. Если необходимо, это может вызывать загрузку модулей. Программный интерфейс, используемый для загрузки модулей или для доступа к указанной мета-информации, не определяется языком, но компилятор должен сохранять эту информацию при генерации кода.
    За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик [linking loader]. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.

    Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.

    http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#D
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 27.01.05 16:48
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Пальцем Вы тыкаете не на хозяина, а на все адресное пространство вместе взятое и удаляете его целиком в случае чего. Тем не менее, в случае safe системы, хозяина можно вычислить совершенно точно — ведь информация о связях между объектами известна.

    И вот в этом месте начинается гон. Потому, что в safe системе запросто можно иметь много указателей на одно и то же. Кто будет хозяином этого объекта?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[54]: Эксперимент
    От: Pazak Россия  
    Дата: 27.01.05 23:52
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Давайте-ка, например, поиздеваемся над старым добрым BlackBox.... (Ваш модуль DeskTop = Views из BlackBox)

    СГ>Мой модуль содержит опредение типа MyView расширения типа Views.View. Я создаю объект MyView с помощью процедуры NewMyView() затем регистрирую его в системе и прошу показать с помощью Views.OpenView(). Вот код:
    СГ>Ну и что же, насильно выгружаю мой модуль с определением типа MyView в то время как моя видимость с ним активно работает (то бишь отображается). Выскакивают два окошка с трапами — игнорирую их (close). Вот и все.
    СГ>
  • BlackBox не упал.

    Похоже я чего-то не понимаю. Давайте немного усложним задачу. Теперь у нас в системе несколько десктопов, и каждое View помнит, к какому дектопу принадлежит (то есть имеет ссылку на "свой" десктоп), например для того, чтоб делать ему Inalidate при ресайзе. Вместе с тем и десктопы тоже помнят о списке "своих" View (например для навигации Desktop.GoToNextView() по альт-таб). Имеем: MyView прибит по инвалидности. Вопрос: куда будет производиться GoToNextView() при его отутствии? Ссылка-то уже не валидна и собрана GC, а достаточной интелектуальности для того, чтоб поискать в списке ближайшую валидную у десктопа не заложено. Выходит надо грохать и десктоп тоже. Тогда вопрос №2: кому будут передавать свой Inalidate остальные View, если они ссылаются на грохнутый десктоп? Выходит, что в пустоту, а значит и их тоже надо грохать... Итого имеем: из-за ошибки в одном конкретном MyView приходится убить все View, принадлежащие данному десктопу, что есть кривь и нарушение защиты.

    СГ>Ну, что, съели? Еще возникать будете? Может еще какой-нибудь эксперимент поставим?


    BTW: я в принципе не против поэкспериментировать, но при одном уловии: если OberonOS без проблем встанет на VMWare. Не хочется, знаете ли пробовать на живом компе... Ну и естественно скорости выполнения эксперимента не гарантирую — как руки дойдут — так и займусь (может быть).
  • Ку...
    Re[54]: А если подумать?
    От: Трурль  
    Дата: 28.01.05 05:53
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом движении надо было тачку перезагружать

    К>Это кайф
    А ведь и 95, 3.x использовали аппаратную защиту памяти. Не помогло.
    Re[55]: А если подумать?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 28.01.05 07:32
    Оценка:
    Здравствуйте, Трурль, Вы писали:

    Т>Здравствуйте, Курилка, Вы писали:


    К>>Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом движении надо было тачку перезагружать

    К>>Это кайф
    Т>А ведь и 95, 3.x использовали аппаратную защиту памяти. Не помогло.

    Ну видимо коль 95 не помогло, то в Обероне решили вообще на неё забить — фигли мучаться и процессорное время сьедать?
    Re[55]: А если подумать?
    От: Sergey Россия  
    Дата: 28.01.05 08:12
    Оценка:
    Hello, Трурль!
    You wrote on Fri, 28 Jan 2005 05:53:15 GMT:

    К>> Ну да, придём обратно к виндовз 95 или раньше, когда при почти любом

    К>> движении надо было тачку перезагружать Это кайф
    Т> А ведь и 95, 3.x использовали аппаратную защиту памяти. Не помогло.

    В 3.х — насколько помню, не использовали.
    В 95 часть GDI и USER были 16-битные, то бишь нереентерабельные (Win16Mutex,
    ха-ха), схема CopyOnWrite поддерживалась программно, на уровне функции
    WriteProcessMemory. Были там и другие корки, но указанных уже достаточно для
    того, чтобы операционка была ненадежной — например, убиение задачи,
    захватившей Win16Mutex приводило догадайтесь сами к чему.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 08:15
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Пальцем Вы тыкаете не на хозяина, а на все адресное пространство вместе взятое и удаляете его целиком в случае чего. Тем не менее, в случае safe системы, хозяина можно вычислить совершенно точно — ведь информация о связях между объектами известна.

    S>И вот в этом месте начинается гон. Потому, что в safe системе запросто можно иметь много указателей на одно и то же. Кто будет хозяином этого объекта?

    Каждый ровно на 1/N.
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: DJ KARIES Россия  
    Дата: 28.01.05 09:50
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>А что будет у нас в Обероне, если прибить модуль System, например?

    Таки отвечу вопросом на вопрос.
    Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе?
    Ибо некошерно.
    ... << http://dkdens.narod.ru :: http://retroforth.org >>
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 09:54
    Оценка:
    AVC пишет:

    > Ш>Ну может быть, всё же не надо дезинформировать общественность. На

    > Марс летал vxWorks, написанный на C.
    > (С достоинством, тщательно выговаривая каждый слог ) Я стараюсь не
    > дезинформировать общественность.
    > Действительно, некоторые страны (мне известно о Канаде и UK)
    > ограничивают применение Си/Си++ в критических областях, прежде всего в
    > области ПО для атомной энергетики.

    В этих областях вообще все ограничивают. И большую часть софта пишут на Ada.

    > Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и

    > сложные проекты.
    > И какие из них *САМЫЕ КРУПНЫЕ*?

    Windows, например Да вообще почти весь софт.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 10:38
    Оценка:
    DJ KARIES пишет:

    > C>А что будет у нас в Обероне, если прибить модуль System, например?

    > Таки отвечу вопросом на вопрос.
    > Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе?
    > Ибо некошерно.

    lsass может прибить только администратор (проверьте сами ), а вот в
    OberonOS — все равны, привиллегий нет.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[61]: Нужна ли Оберон-ОС защита памяти?
    От: Зверёк Харьковский  
    Дата: 28.01.05 11:03
    Оценка:
    Здравствуйте, _vovin, Вы писали:

    _>http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/18422

    _>http://c2.com/cgi/wiki?HeInventedTheTerm
    Класс!
    Даже если это и анекдот, то великолепный!
    (заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )
    сам слушаю и вам рекомендую: silent
    FAQ — це мiй ай-кью!
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 28.01.05 11:20
    Оценка:
    Здравствуйте, prVovik, Вы писали:

    V>Неужели, они ситсемы реального времени пишут на Обероне?

    hard-real time system XO/2 написана на Обероне.
    V>Короче, ГЦ и СРВ — это вещи несовместимые.
    И, представьте себе, со сборщиком мусора.
    Re[63]: Нужна ли Оберон-ОС защита памяти?
    От: Зверёк Харьковский  
    Дата: 28.01.05 11:25
    Оценка:
    Здравствуйте, Трурль, Вы писали:

    ЗХ>>Класс!

    ЗХ>>Даже если это и анекдот, то великолепный!
    ЗХ>>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )
    Т>

    I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.


    Именно это я и имель в виду
    сам слушаю и вам рекомендую: silent
    FAQ — це мiй ай-кью!
    Re[62]: Нужна ли Оберон-ОС защита памяти?
    От: _vovin http://www.pragmatic-architect.com
    Дата: 28.01.05 11:26
    Оценка:
    Здравствуйте, Зверёк Харьковский, Вы писали:

    ЗХ>Здравствуйте, _vovin, Вы писали:


    _>>http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/18422

    _>>http://c2.com/cgi/wiki?HeInventedTheTerm
    ЗХ>Класс!
    ЗХ>Даже если это и анекдот, то великолепный!

    Это реальная история, ставшая фольклором.
    Вторая ссылка содержит рассказ очевидца, так что действительность довольно близка к байке:

    I was in the room when this happened, some time in the second half of the 1980s. The presentation was on Oberon, before anyone had really heard of it. It was basically a "what I did on my summer vacation" talk given by a quality engineer who had dropped by Wirth's lab while he was vacationing in Europe. The announcement really played up that this was the next big object-oriented system, so that's why Alan lowered the boom on the guy like that. The thing that amazed me was that the presenter just went right on like nothing had happened. I think I would have gathered up my slides, thanked the audience, and walked out!

    I recall Alan's answer as being more like "Well, I invented the term, so I think I have something to say about it." He did NOT say his name, and I don't think most of the folks in the room recognized him (including the presenter), so the, um, impact of his statement was perhaps not as great as one might expect. Steve and I got a really good chuckle out of it though.

    -- JoshuaSusser


    ЗХ>(заметим в скобках, что с Кея сталось бы стебаться в том же стиле и над плюсами/шарпами/явами )


    Там чел сам напросился.

    А насчет жавы Кей высказывался мимоходом в одной из своих лекций.
    Типа того, что она годится разве что для курсов выходного дня. Но ее не стоит преподавать в университетах и преподносить как какое-то достижение в Computer Science.
    Также там звучали слова вроде boring, harm, и т.д.
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 11:31
    Оценка:
    Трурль пишет:

    > V>Неужели, они ситсемы реального времени пишут на Обероне?

    > hard-real time system XO/2 написана на Обероне.
    > V>Короче, ГЦ и СРВ — это вещи несовместимые.
    > И, представьте себе, со сборщиком мусора.

    Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в
    2 раза по памяти, по сравнению с non-realtime GC).

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 28.01.05 11:54
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Разница в том, что в "обычной ОС" на этом этапе прибиваются все разделяемые ресурсы, захваченные убитым процессом. В Обероне в лучшем случае удастся отпустить ссылки, которыми владел убиваемый активный объект. Порожденные им объекты, доступные из других активных объектов, продолжат свое существование. Давайте рассмотрим абстрактный пример: наш активный объект создал окно. Конечно же, он передал ссылку на окно оконной подсистеме, чтобы та могла (к примеру) показать это окно в таскбаре. Случилось так, что АО должен умереть. Ок, теперь у нас осталась только одна ссылка на окно: та, что из оконной подсистемы. Упс, процесс умер, но окна его живут. А?


    Хороший пример.
    Давайте попробуем разобраться вместе.

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

    Процессы уже не могут взаимодействовать друг с другом напрямую, минуя специальные механизмы межпроцессного взаимодействия, находящиеся под контролем ядра ОС.
    Ведь чтобы взаимодействовать напрямую, процессы должны иметь прямой доступ к разделяемым ими переменным.
    А такого доступа нет. Ведь у каждого процесса своя копия статических переменных общих прикладных модулей.
    По завершении работы процесса все его прикладные модули могут быть безбоязненно выгружены, т.к. не используются более ни одним процессом.
    Такое решение кажется очень похожим на разделяемые адресные пространства, практикуемые "нормальными" ОС.
    Но есть одно существенное различие. Все приложения по-прежнему находятся в одном адресном пространстве с ядром ОС.
    Не требуется никакого переключения контекста для вызова системных функций.
    Защита приложений друг от друга осуществляется единственно надежностью статической и динамической типизации Оберона.
    Т.е. в самом существенном пункте это по-прежнему Обероновский, а не "нормальный" подход.
    Ведь нетрудно сделать умозаключение по принципу ассоциативности и сделать вывод: если все приложения находятся в одном адресном пространстве с ядром ОС, то в данной системе и существует только одно адресное пространство, а не множество пространств, как это обстоит в "нормальных" системах.
    (Мне кажется, что Сергей своими рассуждениями о "компонентах связности" пытался выразить сходную мысль, но ему несколько помешала его горячность.)
    Ясно, что вызов процедур ядра по-прежнему будет очень быстрым.
    Для экономии памяти можно предложить, чтобы код одного и того же модуля (если он не менялся) был представлен лишь однажды. Копии создаются только для сегментов данных.
    К сожалению, межпроцессное взаимодействие существенно усложняется, но не более, чем в "нормальных" ОС.


    Вот теперь, вооружившись таким подходом, попытаемся разобраться в Вашем вопросе.
    Упомянутая Вами оконная система, в которой сохранилась ссылка на убитое окно, может содержаться либо в прикладных модулях (вроде того, как раньше ваяли вполне приличные графические приложения под DOS Extender'ом ), либо в модулях ядра (вроде того, как сейчас в "Виндах").
    В первом случае, проблема решается автоматически, т.к. модули оконной системы выгружаются вместе с приложением.
    Во втором случае, решение проблемы не намного сложнее. Ядро хранит указатель на объект приложения вместе с указателем на дескриптор соответствующего приложения. Когда работа приложения завершается (в т.ч. по причине "плохого поведения" ), ядро рассылает всем своим контейнерам broadcast-овое сообщение: удалить все указатели на объекты, связанные с таким-то дескриптором процесса.
    Как видите, в обоих мыслимых случаях решение проблемы не представляет труда. (По крайней мере, мне так сейчас кажется. )
    При этом вовсе не требуется введения отдельных адресных пространств, которые следовало бы бдительно отслеживать.

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 28.01.05 12:11
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Realtime GC действительно возможен, но с бааальшим оверхедом (минимум в

    C>2 раза по памяти, по сравнению с non-realtime GC).

    Возможен с бааальшим оверхедом, а возможен и с небольшим. В XO/2 выбрали второе.
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 28.01.05 12:18
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:


    C>В этих областях вообще все ограничивают. И большую часть софта пишут на Ada.


    И на Модула-2.
    Собственно, только Ада и Модула-2 "разрешены" повсеместно.
    Говорят, что дело прежде всего в наличии у них стандартов ISO.

    >> Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и

    >> сложные проекты.
    >> И какие из них *САМЫЕ КРУПНЫЕ*?

    C>Windows, например Да вообще почти весь софт.


    Изначально Windows были написаны на Паскале.
    Затем переписаны на Си.
    Сейчас некоторая часть Windows написана на Си++.
    Значит ли это, что Windows — именно Си++-ный проект?
    Вряд ли.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 12:27
    Оценка:
    AVC пишет:

    >>> Ш>Не понятно только, почему на С/C++ разрабатывются наиболее крупные и

    >>> сложные проекты.
    >>> И какие из них *САМЫЕ КРУПНЫЕ*?
    > C>Windows, например Да вообще почти весь софт.
    > Изначально Windows были написаны на Паскале.
    > Затем переписаны на Си.

    Врут Легенда родилась из-за распространенности PASCAL calling
    convention в Винде.

    > Сейчас *некоторая* часть Windows написана на Си++.


    Да, а остальная — на C&asm.

    > Значит ли это, что Windows — именно Си++-ный проект?

    > Вряд ли.

    Тут ссылки уже приводили У Adobe'а все продукты на С++, например.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 28.01.05 12:31
    Оценка:
    Hello, AVC!
    You wrote on Fri, 28 Jan 2005 11:54:28 GMT:

    A> а тактическая. Поскольку вопрос о статических указателях оказался не

    A> таким простым (по крайней мере, для меня ), я решил
    A> разобраться сначала с более простым вариантом единого адресного
    A> пространства. Какими особенностями обладает предлагаемый подход?

    Собственно, к единому адресному пространству как таковому у меня, например,
    претензий не было. Я несогласен с другим утверждением — "GC и строгая
    типизация достаточны для реализации надежной ОС с единым адресным
    пространством, при это все модули, включая ядро, для рантайма равноценны. И
    дохлых указателей при этом не бывает". Именно это, как мне показалось,
    пытался утверждать Губанов.

    A> [q]

    A> Процессы уже не могут взаимодействовать друг с другом
    A> напрямую, минуя специальные механизмы межпроцессного
    A> взаимодействия, находящиеся под контролем ядра ОС. Ведь чтобы
    A> взаимодействовать напрямую, процессы должны иметь прямой
    A> доступ к разделяемым ими переменным. А такого доступа нет. Ведь у
    A> каждого процесса своя копия статических переменных общих прикладных
    A> модулей. По завершении работы процесса все его прикладные модули могут
    A> быть безбоязненно выгружены, т.к. не используются более ни одним
    A> процессом. Такое решение кажется очень похожим на разделяемые адресные
    A> пространства, практикуемые "нормальными" ОС. Но есть одно
    A> существенное различие. Все приложения по-прежнему находятся в
    A> одном адресном пространстве с ядром ОС.

    ...что на платформе х86 не так уж и здорово по причине этого самого
    адресного пространства ограниченности.

    A> Не требуется никакого переключения контекста для вызова системных

    A> функций. Защита приложений друг от друга осуществляется единственно
    A> надежностью статической и динамической типизации Оберона.

    Этого не достаточно. Поскольку раз некоторые объекты убиваются не по
    алгоритмам сборки мусора, могут образоваться висящие указатели. В принципе,
    я могу представить GC, который висящих указателей даже в такой ситуации не
    допустит и, скажем, их обнулит. Но это опять-таки перекладывание проблемы на
    программиста — он то может и не ожидать, что у него объекты, ссылки на
    которые он держит, пропадать начнут и вместо вызова их методов полетят
    исключения.

    A> модули оконной системы выгружаются вместе с приложением. Во втором

    A> случае, решение проблемы не намного сложнее. Ядро хранит указатель на
    A> объект приложения вместе с указателем на дескриптор соответствующего
    A> приложения
    .

    То бишь, подобие хэндла. Но, IMHO, пока далекое от совершенства.

    A> Когда работа приложения завершается (в т.ч. по причине "плохого

    A> поведения" ), ядро рассылает всем своим контейнерам broadcast-овое
    A> сообщение: удалить все указатели на объекты, связанные с таким-то
    A> дескриптором процесса. Как видите, в обоих мыслимых случаях решение
    A> проблемы не представляет труда.

    Но оно — не автоматическое, как тут кое-кто (не будем показывать пальцем,
    все и так знают, что это Губанов) обещал.

    A> (По крайней мере, мне так сейчас

    A> кажется. )

    Чтоб так не казалось, имеет смысл подумать над вопросом — а откуда ядро
    берет указатель на дескриптор соответствующего
    приложения? И попытаться изобрести такую схему, которую невозможно
    обмануть.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 28.01.05 13:03
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Собственно, к единому адресному пространству как таковому у меня, например,

    S>претензий не было. Я несогласен с другим утверждением — "GC и строгая
    S>типизация достаточны для реализации надежной ОС с единым адресным
    S>пространством, при это все модули, включая ядро, для рантайма равноценны. И
    S>дохлых указателей при этом не бывает". Именно это, как мне показалось,
    S>пытался утверждать Губанов.

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

    S>...что на платформе х86 не так уж и здорово по причине этого самого

    S>адресного пространства ограниченности.

    Та же Bluebottle поддерживает виртуальную память, насколько я понял из ее описания.

    A>> Не требуется никакого переключения контекста для вызова системных

    A>> функций. Защита приложений друг от друга осуществляется единственно
    A>> надежностью статической и динамической типизации Оберона.
    S>Этого не достаточно. Поскольку раз некоторые объекты убиваются не по
    S>алгоритмам сборки мусора, могут образоваться висящие указатели.

    Нет, в предложенном мной варианте все указатели обслуживаются одним единственным GC.
    Просто системные дескрипторы "финализируются" (в случае необходимости) соответствующими процедурами ядра.

    S>В принципе, я могу представить GC, который висящих указателей даже в такой ситуации не

    S>допустит и, скажем, их обнулит. Но это опять-таки перекладывание проблемы на
    S>программиста — он то может и не ожидать, что у него объекты, ссылки на
    S>которые он держит, пропадать начнут и вместо вызова их методов полетят
    S>исключения.

    См. выше.

    A>> Когда работа приложения завершается (в т.ч. по причине "плохого

    A>> поведения" ), ядро рассылает всем своим контейнерам broadcast-овое
    A>> сообщение: удалить все указатели на объекты, связанные с таким-то
    A>> дескриптором процесса. Как видите, в обоих мыслимых случаях решение
    A>> проблемы не представляет труда.

    S>Но оно — не автоматическое, как тут кое-кто (не будем показывать пальцем,

    S>все и так знают, что это Губанов) обещал.

    A>> (По крайней мере, мне так сейчас

    A>> кажется. )

    S>Чтоб так не казалось, имеет смысл подумать над вопросом — а откуда ядро

    S>берет указатель на дескриптор соответствующего
    S> приложения? И попытаться изобрести такую схему, которую невозможно
    S>обмануть.

    Я и пытаюсь это сделать.
    Просто сделать это "одним махом" мне ума не хватает.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 28.01.05 13:33
    Оценка:
    Hello, AVC!
    You wrote on Fri, 28 Jan 2005 13:03:28 GMT:

    A> Как мне кажется, я тоже утверждаю именно это.


    В том числе, что при выгрузке модулей без специальных мер не могут
    образоваться дохлые указатели?

    A> Так что я согласен с Сергеем (если, конечно, мне не докажут, что это

    A> неправильная точка зрения). Кстати, в приведенном мной примере
    A> единственная разница между модулями ядра и прикладными модулями
    A> состоит в том, что модули ядра загружаются однократно и не выгружаются.
    A> Т.е. это различие касается только динамического загрузчика. Во всем
    A> же остальном
    модули ядра и прикладные модули для рантайма
    A> равноценны.

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

    S>> ...что на платформе х86 не так уж и здорово по причине этого самого

    S>> адресного пространства ограниченности.

    A> Та же Bluebottle поддерживает виртуальную память, насколько я понял из

    A> ее описания.

    И что, она может быть больше 4Gb?

    A>>> Не требуется никакого переключения контекста для вызова системных

    A>>> функций. Защита приложений друг от друга осуществляется единственно
    A>>> надежностью статической и динамической типизации Оберона.
    S>> Этого не достаточно. Поскольку раз некоторые объекты убиваются не по
    S>> алгоритмам сборки мусора, могут образоваться висящие указатели.

    A> Нет, в предложенном мной варианте все указатели обслуживаются

    A> одним единственным GC.
    Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули
    выгружаем, но объекты из них остаются ?

    A> Просто системные дескрипторы "финализируются" (в случае необходимости)

    A> соответствующими процедурами ядра.

    Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...

    S>> В принципе, я могу представить GC, который висящих указателей даже в

    S>> такой ситуации не допустит и, скажем, их обнулит. Но это опять-таки
    S>> перекладывание проблемы на программиста — он то может и не ожидать, что
    S>> у него объекты, ссылки на которые он держит, пропадать начнут и вместо
    S>> вызова их методов полетят исключения.

    A> См. выше.

    А то, что выше — это тоже перекладывание проблемы на программиста. Он,
    кстати, может и не догадаться, что в данном конкретном случае дескриптор
    нужен.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 13:48
    Оценка:
    Здравствуйте, DJ KARIES, Вы писали:

    DK>Здравствуйте, Cyberax, Вы писали:


    C>>А что будет у нас в Обероне, если прибить модуль System, например?

    DK>Таки отвечу вопросом на вопрос.
    DK>Ведь же вы не прибиваете lsass.exe или kernel.32 на своей C++системе?
    DK>Ибо некошерно.

    Дело не в этом. Модуль SYSTEM на самом деле является псевдо модулем интегрированным в компилятор. Выгрузить его нельзя просто потому что его реально не существует. То есть модуль SYSTEM даже не является частью операционной системы.




    Вместо модуля SYSTEM лучше рассмотреть модуль Kernel.

    Например, в БлэкБоксе именно в модуле Kernel определена процедура выгрузки модулей:
    PROCEDURE UnloadMod (mod: Kernel.Module);

    Я пытался с помощью нее выгрузить сам модуль Kernel, так ничего не вышло, вызов был просто проигнорирован.
    Re[59]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 28.01.05 14:07
    Оценка:
    Hello, Poudy!
    You wrote on Fri, 28 Jan 2005 13:55:40 GMT:

    S>> В том числе, что при выгрузке модулей без специальных мер не могут

    S>> образоваться дохлые указатели?
    P> "Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не
    P> образуются на что попало. Т.к. во-превых: указатель на объект другого
    P> модуля — это не просто указатель, во-вторых: всё остальное является
    P> копиями. Главное, что дохлый указатель — это правильный
    P> указатель, т.е. null или ссылка на InvalidObject, а не мусор.

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

    S>> И что, она может быть больше 4Gb?

    P> На самом деле, если ты всегда обращаешься по управляемому указателю и GC
    P> один на всех, то памяти может сколько угодно.

    Да, про это я не подумал.

    S>> Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули

    S>> выгружаем, но объекты из них остаются ?
    P> Как я понимаю модуль — это единица кода. Данные тут ваще не при чём.
    P> Вы до сих пор не воткнули , что модуль — это не аналог процесса.
    P> Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

    Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код и
    данные этой задачи. Получатся дохлые указатели. Так понятней?

    A>>> Просто системные дескрипторы "финализируются" (в случае необходимости)

    A>>> соответствующими процедурами ядра.
    S>> Ну видишь, уже понадобились дескрипторы и соответствующие процедуры...
    P> А то.

    Вот Губанову это и объясни

    P> Обычно C++ гуру называют таких программистов безнадежными, жертва

    P> аборта, ошибка ДНК. Так что можно расслабиться.

    Нельзя расслабится. Такая ситуация легко может возникнуть у самого что ни на
    есть гуру при не слишком тщательном рефакторинге. Это должно быть запрещено
    автоматически, на уровне языка или на уровне операционки.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 28.01.05 14:19
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x

    C>оверхедом.
    Ваше "серьезно говорю" можно понимать как:
    1) Доказано, что realtime-GC требует >= 2x оверхеда.
    2) В настоящее время не существует realtime-GC с < 2x оверхедом.
    3) Вам лично такие системы неизвестны.
    Я могу безусловно согласиться только с последним вариантом.
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 14:31
    Оценка:
    Трурль пишет:

    > C>Я серьезно говорю — асинхронный realtime-GC возможен минимум с 2x

    > C>оверхедом.
    > Ваше "серьезно говорю" можно понимать как:
    > 1) Доказано, что realtime-GC требует >= 2x оверхеда.
    > 2) В настоящее время не существует realtime-GC с < 2x оверхедом.

    Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 28.01.05 14:38
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.

    А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который возможен минимум с 2x
    оверхедом".
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 14:44
    Оценка:
    СГ> Я пытался с помощью нее выгрузить сам модуль Kernel, так ничего не вышло, вызов был просто проигнорирован.

    Извиняюсь, запарил. Не только его нельзя выгрузить, а вообще никакой модуль нельзя выгрузить пока у него есть клиенты, т.е. пока его кто-то импортирует. Выгружать модули надо начиная с листьев дерева импорта модулей (с тех, которые уже никто более не импортирует).
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 28.01.05 14:45
    Оценка:
    Трурль пишет:

    > C>Подчеркиваю: _асинхронного_ GC. Синхронный GC можно сделать.

    > А что Вы вкладываете в термин "асинхронный"? Надеюсь, не "тот, который
    > возможен минимум с 2x
    > оверхедом".

    Запускающийся независимо от желаний приложения, и работающий сколько ему
    захочется...

    Синхронный GC запускается явно по требованию.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[60]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 28.01.05 14:47
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>>> В том числе, что при выгрузке модулей без специальных мер не могут

    S>>> образоваться дохлые указатели?
    P>> "Дохлые указатели" — это вполне нормально. Вполне себе ясно, что они не
    P>> образуются на что попало. Т.к. во-превых: указатель на объект другого
    P>> модуля — это не просто указатель, во-вторых: всё остальное является
    P>> копиями. Главное, что дохлый указатель — это правильный
    P>> указатель, т.е. null или ссылка на InvalidObject, а не мусор.

    S>Во-во, что я пытаюсь объяснить. "Дохлые указатели" — вполне нормально, но

    S>они кардинально усложняют ситуацию.
    Да ничего не кардинально. Я почти уверен, что в BlueBottle используется механизм similar to AppDomain.
    Тебе так мешают жить указатели на удаленные объекты? (слово-то какое Широка семантика русского языка — объект, находящийся на другой машине есть удаленный объект )

    S>>> Т.е., модули мы по желанию пользователя таки не выгружаем? Или модули

    S>>> выгружаем, но объекты из них остаются ?
    P>> Как я понимаю модуль — это единица кода. Данные тут ваще не при чём.
    P>> Вы до сих пор не воткнули , что модуль — это не аналог процесса.
    P>> Модуль — это что-то типа Dll. А процесс, нить — это активный объект.

    S>Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код и

    S>данные этой задачи. Получатся дохлые указатели. Так понятней?
    Я понимаю это так: модуль при старте может создавать активный объект — это и есть объект собственно модуля. Во всех других модулях данный модуль виден тока как код. Для каждого модуля существуют копии всех статических переменных других модулей (пусть Губанов поправит, если не так). Соотв если есть модульи А и Б, и я создал в активном объекте модуля А простой объект модуля Б, то этот объект принадлежит модулю А, также как и все копии статических переменных модуля Б. В этом смысле модуль упасть не может принципиально. Грохаются только активные объекты и все принадлежащие им объекты. Если в грохаемом объекте есть ссылка на объекты принадлежащие активным объектам других модулей (а не принадлежащие классам, определенным в других модулях), то такие объекты остаются живы и требуют отдельной обработки (как в слечае с хендлами, вероятно). Но все объекты данного активного объекта модуля грохаются. Вощем, смотри AppDomain, Remoting и т.д.

    P>> Обычно C++ гуру называют таких программистов безнадежными, жертва

    P>> аборта, ошибка ДНК. Так что можно расслабиться.

    S>Нельзя расслабится. Такая ситуация легко может возникнуть у самого что ни на

    S>есть гуру при не слишком тщательном рефакторинге. Это должно быть запрещено
    S>автоматически, на уровне языка или на уровне операционки.
    Та это невозможно. Что возможно (теоретически), так это доказать, что такое невозможно . На самом деле CannotAccessDisposedObjectException — это и есть решение "на уровне операционки".

    S>With best regards, Sergey.
    Re[61]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 28.01.05 15:13
    Оценка:
    Hello, Poudy!
    You wrote on Fri, 28 Jan 2005 14:47:20 GMT:

    S>> Во-во, что я пытаюсь объяснить. "Дохлые указатели" — вполне нормально,

    S>> но они кардинально усложняют ситуацию.
    P> Да ничего не кардинально.
    Ну это кому как.

    P> Я почти уверен, что в BlueBottle используется механизм similar to

    P> AppDomain. Тебе так мешают жить указатели на удаленные объекты?
    P> (слово-то какое
    Лично мне — очень. Я сейчас как раз нечто подобное пишу, только на плюсах

    S>> Блин, выгрузится дохлая задача — выгрузятся кой-какие модули. Весь код

    S>> и данные этой задачи. Получатся дохлые указатели. Так понятней?
    P> Я понимаю это так: модуль при старте может создавать активный объект -
    P> это и есть объект собственно модуля. Во всех других модулях данный
    P> модуль виден тока как код. Для каждого модуля существуют копии всех
    P> статических переменных других модулей (пусть Губанов поправит, если не
    P> так). Соотв если есть модульи А и Б, и я создал в активном объекте
    P> модуля А простой объект модуля Б, то этот объект принадлежит модулю А,
    P> также как и все копии статических переменных модуля Б. В этом смысле
    P> модуль упасть не может принципиально.

    Ладно, буду говорить "Активный Объект"

    P> Грохаются только активные объекты и все принадлежащие им объекты.

    P> Если в грохаемом объекте есть ссылка на объекты принадлежащие
    P> активным объектам других модулей (а не принадлежащие классам,
    P> определенным в других модулях), то такие объекты остаются живы и требуют
    P> отдельной обработки (как в слечае с хендлами, вероятно).

    Гораздо важнее вопрос, что делать с объектами, ссылающимися на убиваемый
    объект.

    S>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого что

    S>> ни на есть гуру при не слишком тщательном рефакторинге. Это должно быть
    S>> запрещено автоматически, на уровне языка или на уровне операционки.
    P> Та это невозможно. Что возможно (теоретически), так это доказать, что
    P> такое невозможно .

    Да ну. Запретить объектам из одной задачи ссылаться на объекты другой таким
    же образом, что и на объекты своей задачи — невозможно? Ну докажи попробуй.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[62]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 28.01.05 15:49
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого что

    S>>> ни на есть гуру при не слишком тщательном рефакторинге. Это должно быть
    S>>> запрещено автоматически, на уровне языка или на уровне операционки.
    P>> Та это невозможно. Что возможно (теоретически), так это доказать, что
    P>> такое невозможно .

    S>Да ну. Запретить объектам из одной задачи ссылаться на объекты другой таким

    S>же образом, что и на объекты своей задачи — невозможно? Ну докажи попробуй.
    Весь мир идет к тому, чтобы не делать различий, а ты хочешь всё вернуть .
    Я понимаю всю головную боль, но пока что такие вещи решаются написанием оберток
    Да, вероятно было было бы неплохо иметь в удаленной ссылке автоматом событие Disconnected и т.д.

    А невозможно сделать так, чтобы объект был не твой и удаляемый, но всё работало само как надо.
    Re[61]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 15:56
    Оценка:
    Здравствуйте, Poudy, Вы писали:

    P> Я понимаю это так: модуль при старте может создавать активный объект — это и есть объект собственно модуля.


    В принципе он может создать не один а сколько угодно активных объектов...

    P> Для каждого модуля существуют копии всех статических переменных других модулей (пусть Губанов поправит, если не так).


    Копий нет:
    MODULE M
      VAR K: INTEGER;
    END M.

    переменная M.K — одна на всю систему.
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 28.01.05 16:09
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Вопрос.

    СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

    Сергей, а ты знаешь как Garbage Collector переводится и что делает?
    Re[63]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 28.01.05 16:25
    Оценка:
    Hello, Poudy!
    You wrote on Fri, 28 Jan 2005 15:49:26 GMT:

    S>>>> Нельзя расслабится. Такая ситуация легко может возникнуть у самого

    S>>>> что ни на есть гуру при не слишком тщательном рефакторинге. Это
    S>>>> должно быть запрещено автоматически, на уровне языка или на уровне
    S>>>> операционки.
    P>>> Та это невозможно. Что возможно (теоретически), так это доказать, что
    P>>> такое невозможно .

    S>> Да ну. Запретить объектам из одной задачи ссылаться на объекты другой

    S>> таким же образом, что и на объекты своей задачи — невозможно? Ну докажи
    S>> попробуй.
    P> Весь мир идет к тому, чтобы не делать различий, а ты хочешь всё вернуть
    P> .

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

    P> А невозможно сделать так, чтобы объект был не твой и удаляемый, но всё

    P> работало само как надо.

    Разумеется.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 28.01.05 16:26
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Вопрос.

    СГ>>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

    К>Сергей, а ты знаешь как Garbage Collector переводится и что делает?


    Ну, я имел ввиду весь менеджер памяти неотделимой частью которого является GC.
    NEW(p) — запускает его, стало быть, в некотором смысле, может рассматриваться как завуалированный вызов GC если он вдруг нужен. Если мы долгое время не вызываем NEW(p), то GC преспокойно может это самое долгое время ничего не делать. Зачем напрягаться понапрасну? Так или нет?
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 28.01.05 16:28
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Курилка, Вы писали:


    К>>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>>Вопрос.

    СГ>>>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

    К>>Сергей, а ты знаешь как Garbage Collector переводится и что делает?


    СГ>Ну, я имел ввиду весь менеджер памяти неотделимой частью которого является GC.


    Сборщик мусора является лишь частью менеджера памяти и соответственно остальные части менеджера сборщиком не являются, так что не надо тут софизмы изрекать, плиз
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 28.01.05 18:05
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Вопрос.

    СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?

    Да, но только в случае однозадачной системы.
    Еще придется располагать временнЫми гарантиями работы ГЦ
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Pazak Россия  
    Дата: 29.01.05 00:46
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    >>> возможен минимум с 2x

    >>> оверхедом".
    C>>Запускающийся независимо от желаний приложения, и работающий сколько ему
    C>>захочется...
    C>>Синхронный GC запускается явно по требованию.
    СГ>Можно ли каждый вызов инструкции NEW(p); считать как завуалированное требование вызова GC?
    СГ>Ведь, по идее, если мы не вызываем NEW(p), то зачем GC напрягаться-то(???), он может спокойно курить... а вот как только мы вызвали NEW(p), так он сразу — если есть память, то мгновенно ее возвращает, а если нет, то тут он напрягается, трудится-работает убирает мусор, как только уберет сколько затребовали, возвращает ее и дальше курит...

    Да, но в системе реального времени в дело вступает еще один фактор: достаточно ли у GC времени на то, чтоб завершить свою работу. И память должна выделиться независимо от того, достаточно или недостаточно. Стало быть для гарантированного выделения N байт памяти эти N байт должны быть уже свободны в системе, а GC при вызове должен трудиться над очисткой уже следующих N байт для сделующего гарантированного выделения памяти. Думаю Cyberax именно это имел в виду, когда говорил, что необходим 2x overhead.
    Ку...
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: Pazak Россия  
    Дата: 29.01.05 00:46
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

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


    Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?

    ЗЫ Просьба не цепляться к словам, если не нравится "не-обероновский" термин "приложение" можем считать его "активным объекто типа TApplication" или еще чем-то, главное чтоб сохранилась суть.
    Ку...
    Re[62]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 29.01.05 10:04
    Оценка:
    Сергей Губанов пишет:

    > P> Для каждого модуля существуют копии всех статических переменных

    > других модулей (пусть Губанов поправит, если не так).
    > Копий нет:
    >
    >MODULE M
    > VAR K: INTEGER;
    >END M.
    >
    > переменная M.K — одна на всю систему.

    То есть, если пользователь Вася загрузит модуль "Photoshop", то
    пользователь Петя уже не сможет его загрузить?

    Или Оберон — исключительно однопользовательский?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 29.01.05 12:03
    Оценка:
    Здравствуйте, Pazak, Вы писали:

    P>Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?


    P>ЗЫ Просьба не цепляться к словам, если не нравится "не-обероновский" термин "приложение" можем считать его "активным объекто типа TApplication" или еще чем-то, главное чтоб сохранилась суть.

    И всё равно есть постоянная подмена понятий и путаница в словах. Сначала ты говоришь "Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение?", а потом "что произойдет с остальными N-1 приложениями, использующими данный модуль". Какой модуль? А? Или модуль приложения? С модулем А ничего не произойдет, потому что: а — это код, б — его объекты ни в чем не виноваты. С другими приложениями, полагающимися на приложение TApplication произойдет то же, что и с аськой при падеже сервера: всё зависит от самих асек; как они написаны были, так и будет. Всё-таки остается непонимание вещей, хоть ты и говоришь "главное чтоб сохранилась суть".
    Re[64]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 29.01.05 12:15
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Отучаемся говорить за весь мир Программисту приходится знать, может метод

    S>объекта кинуть исключение или не может. Писать код в условиях, когда любой
    S>метод любого объекта может кинуть исключение сложнее, чем когда исключений
    S>нет. Соответственно, от общности в данном конкретном случае помимо пользы
    S>есть и вред.

    Да, вред есть. Да, сложно писать, когда всё может кинуть исключение. Но в данном случае я не понимаю:
    а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие могут находиться удаленно и пр.?
    б — неужто приватные Hashtable могут кидать исключения и это составляет проблему?
    в — для удаленных объектов существуют (должны, по крайней мере) методы вклинивания в вызовы. На крайняк можно написать обертку.
    г — все глобальный проблемы надежности подобных штук решаются только повышением надежности. Как много программ на Java или C# закладываются на какой-нибудь NotEnougthMemoryException или UndefinedBehaviorException при new ?

    Или ты хочешь сделать какую-нибудь систему, вроде GC или проверки выхода за границы массива, но только для распределенной работы? Хмм.. Это потянет на докторскую. Быть может даже в этом есть резон. Быть может даже трудов 50 на это дело написано.
    Re[65]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 31.01.05 16:34
    Оценка:
    Hello, Poudy!
    You wrote on Sat, 29 Jan 2005 12:15:59 GMT:

    S>> Отучаемся говорить за весь мир Программисту приходится знать, может

    S>> метод объекта кинуть исключение или не может. Писать код в условиях,
    S>> когда любой метод любого объекта может кинуть исключение сложнее, чем
    S>> когда исключений нет. Соответственно, от общности в данном конкретном
    S>> случае помимо пользы есть и вред.

    P> Да, вред есть. Да, сложно писать, когда всё может кинуть исключение.

    P> Но в данном случае я не понимаю:

    P> а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие

    P> могут находиться удаленно и пр.?

    При чем здесь я?
    Программист на Обероне может и не знать — компонентная среда и все такое.

    P>

    б — неужто приватные Hashtable могут
    P> кидать исключения и это составляет проблему?

    При чем здесь Hashtable?

    P>

    в — для удаленных объектов
    P> существуют (должны, по крайней мере) методы вклинивания в вызовы. На
    P> крайняк можно написать обертку.

    Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не читаю.

    P>

    г — все глобальный проблемы надежности
    P> подобных штук решаются только повышением надежности.

    Гы

    P>

    Как много программ
    P> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
    P> или UndefinedBehaviorException при new ?

    Почем я знаю? Лично мне такую возможность часто приходится учитывать.

    P> Или ты хочешь сделать какую-нибудь систему, вроде GC или проверки выхода

    P> за границы массива, но только для распределенной работы?

    Я? Нет. У меня простой RPC с хэндлами. Без GC.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[37]: Что происходит
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 08:57
    Оценка:
    Здравствуйте, Pazak, Вы писали:

    P>Здравствуйте, Сергей Губанов, Вы писали:


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


    P>Э-э-э-э... Гм... Я опять чего-то не понимаю, уж прости чайника любопытного. Вот есть модуль A, который используют N приложений. Одно из приложений вызвало A.DoEndlessLoop() и зависло, отжирая ресурсы. Что произойдет (поледовательно, по шагам), если я попрошу систему выгрузить это приложение? Отдельный вопрос — что произойдет с остальными N-1 приложениями, использующими данный модуль?


    Зависит от системы.
    Могу сказать как обстоят дела в BlackBox, как с остальными системами — надо обращаться к их документации.

    Есть модуль А, внутри него есть процедура DoEndlessLoop(). Как вызвать эту процедуру? Вызвать эту процедуру можно из другой процедуры, которую вызвать из третьей, а ту из четвертой и т.д. в конце концов придем к ситуации что первично курица или яйцо и как вызвать корневую процедуру.

    Есть такое понятие как команда. Мы просим БлэкБокс выполнить команду "A.DoEndlessLoop" вот так вот именно в виде текстовой строки передаем имя модуля и имя процедуры.

    Аналогично в UNIX:
    ./ADoEndlessLoop.out

    или в DOS/Windows:
    ADoEndlessLoop.exe


    Система загружает в память модуль А (если он еще не был загружен до этого), находит в нем процедуру (без параметров) DoEndlessLoop() и активирует ее. Если при выполнении этой процедуры происходит нечто плохое, например, возникает исключительная ситуация (или в терминологии БлэкБокса происходит system trap), то выполнение этой команды останавливается.

    Вот и все.

    В UNIX или в Windows аналогичным образом, например, может завершиться процесс порожденный командами ./ADoEndlessLoop.out или ADoEndlessLoop.exe.

    Можно самому, так сказать, снять задачу, т. е. отменить выполнение зациклившейся команды нажав на Ctrl + Break (хоть и не мгновенно, но срабатывает). Ctrl + Break рассматривается как исключение, порожденное пользователем. Сама процедура может самостоятельно сгенерировать исключительную ситуацию вызвав ASSERT(condition, num); с condition = FALSE — выполнение текущей команды будет остановлено.




    Однако есть существенное отличие между Оберон системами и UNIX/Windows касающееся судьбы переменных:

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


    Если ситема позволяет запускать команды параллельно — то вот Вам, пожалуйста, аналог отдельных процессов UNIX/Windows.
    Re[63]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 09:10
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Сергей Губанов пишет:

    >> Копий нет:
    >>
    >>MODULE M
    >> VAR K: INTEGER;
    >>END M.
    >>
    >> переменная M.K — одна на всю систему.

    C>То есть, если пользователь Вася загрузит модуль "Photoshop", то

    C>пользователь Петя уже не сможет его загрузить?

    C>Или Оберон — исключительно однопользовательский?


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

    Вот Вам три фотошопа одновременно:
    VAR p1,p2,p3: Photoshop.View;
    BEGIN
      p1 := Photoshop.New();
      p2 := Photoshop.New();
      p3 := Photoshop.New();
    
      Views.OpenView(p1);
      Views.OpenView(p2);
      Views.OpenView(p3);


  • Количество загружаемых одновременно программ не связано с одно- или много-пользовательностью системы. В принципе, теоретически, можно вообразить многопользовательскую систему, в которой действительно каждая программа может быть загружена в одном экземпляре. И в которой действительно, Петя и Вася работающие удаленно на одном и том же компьютере не смогут одновременно запустить фотошоп. Мультизадачность и мультипользовательность — ортогональные понятия.
  • Re[57]: Один из способов решения
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 09:15
    Оценка:
    Здравствуйте, Pazak, Вы писали:

    P>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Системный список указателей на пользовательские объекты можно написать так, чтобы он автоматически забывал о плохом объекте, псевдокод:


    P>Можно. А можно и не написать. Разговор-то идет о средствах, обеспечивающих безопасность системы автоматически, вне зависимости от криворукости программиста. А в том, что теоретически можно написать идеальную программу я, конечно, не сомневаюсь. Вот только практика и теория — обычно разные вещи...


    Под системным списоком указателей я имел в виду внутренности ядра системы (или рантайма) — то что скрыто от приложений. А то что приложения будут написаны криво или прямо, на безопасность системы уже не влияет, она уже защищена.
    Re[64]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 01.02.05 09:17
    Оценка:
    Сергей Губанов пишет:

    > # Из того что модульные переменные существуют в единственном экземпляре

    > не следует, что каждая программа может быть запущена в одном экземпляре.
    >
    > Вот Вам три фотошопа одновременно:
    >
    >VAR p1,p2,p3: Photoshop.View;
    >BEGIN
    > p1 := Photoshop.New();
    > p2 := Photoshop.New();
    > p3 := Photoshop.New();
    >
    > Views.OpenView(p1);
    > Views.OpenView(p2);
    > Views.OpenView(p3);
    >
    >
    Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не
    помогает (даже мешает).

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[38]: Что происходит
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 09:40
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ> Если ситема позволяет запускать команды параллельно — то вот Вам, пожалуйста, аналог отдельных процессов UNIX/Windows.


    Например в Aos BlueBottle написанной на языке Active Oberon "тело активного объекта" выполняется параллельно. Гарантируется, что пока активный объект активен, то сборщик мусора его не будет уничтожать даже если внешних ссылок на него не осталось или никогда не было (в ядре хранятся ссылки на все активности), после того как активный объект закончил свою активную деятельность — далее он продолжает "влачить свое существование" уже как обычный объект и будет убит сборщиком мусора как только о нем все забудут.
    TYPE
      MyActiveObject = OBJECT
        (* Переменные объекта *)
         VAR x, y, Vx, Vy: REAL;
    
        (* Методы объекта *)
        PROCEDURE Move()
        BEGIN
        END....
        ...    
      BEGIN {ACTIVE} (* "тело" объекта *)
        (* код приведенный сдесь выполняемый параллельно *)
        (* начинает исполняться после конструирования этого объекта *)
        (* после выполнения этого кода объект перестает быть активным и превращяется в обычный *)
      END;
    Re[65]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 09:43
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не

    C>помогает (даже мешает).

    А если подумать, то можно придумать массу алгоритмов, где будет помогать. Обратитесь к исходникам таких систем...
    Re[53]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 01.02.05 09:55
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Privalov, Вы писали:


    Т>>>А что, в обычных ОСах система может автоматически определить какие процессы следует прибить?

    P>>Что значит "в обычных ОСах"? В OS/360 процесс, который плохо себя вел, прибивался, при этом на АЦПУ выводилась информация о причине его снятия. В Windows выводится окно с предложением убить процесс или перейти в режим отладки. Или это не обычные ОС?

    AVC>А чем в этом отношении Оберон хуже?

    AVC>В Обероне "плохой" процесс убивается, в Log выводится trap text.
    AVC>В данном пункте не вижу разницы.

    В этом все и дело. Но что тогда значит "обычные ОС" в интерпретации г-на Трурля?


    AVC>А вопрос Трурль задал правильный.

    AVC>Противники Оберона постоянно высказываются в том духе, что "убийство процесса" есть главный (чуть ли не единственный) механизм безопасности в ОС.


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

    Так что убийство процесса — результат требования экономного использования ресурсов, а не механизм безопасности.

    AVC>Вот Трурль и задает простой вопрос: как процесс становится "плохим", когда его пора убивать?


    Например, менеджер памяти получил исклэчение "отказ страницы", попытался свопнуть нужнуэ страцицу с диска, при этом при чтении исказилось содержимое страницы . В результате процесс в лучшем случае вылетает из-за неверной команды, в худшем — теряет управление (повредился адрес безусловного перехода).
    Re[66]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 01.02.05 10:07
    Оценка:
    Сергей Губанов пишет:

    > C>Да, но в этом случае мне "синглтонность" модуля абсолютно ничем не

    > C>помогает (даже мешает).
    > А если подумать, то можно придумать массу алгоритмов, где будет
    > помогать. Обратитесь к исходникам таких систем...

    КАКИХ именно систем?

    "Активный объект" — это не более чем обычный поток, а переменные модуля
    — статические переменные, разделяемые всеми тредами. Это делает их
    бесполезными в 99% случаев.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[66]: Нужна ли Оберон-ОС защита памяти?
    От: Poudy Россия  
    Дата: 01.02.05 10:08
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    P>> а — ты разве не знаешь, какие объекты у тебя находятся удаленно, какие

    P>> могут находиться удаленно и пр.?

    S>При чем здесь я?

    S>Программист на Обероне может и не знать — компонентная среда и все такое.
    Ну это глупости на самом деле Программист почти всегда знает что и откуда, и при этом совсем не обязательно расставлять try/catch вокруг любого вызова.

    P>>б — неужто приватные Hashtable могут

    P>> кидать исключения и это составляет проблему?

    S>При чем здесь Hashtable?

    Это в вопросу о том, что ты знаешь что может упать, а что нет.

    P>> в — для удаленных объектов

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

    S>Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не читаю.

    Обертка нужна
    — для получения сообщений о том, что она отвалилась, и изъятии её при этом из разных там коллекций.
    — для попыток переподключения.
    — для сохранения возможности вызвать некоторые свойства уже после того, как объект отвалился (например, кешированное Name или IsAlive = false)

    Под .Net можно, конечно, решить и без обертки — при помощи синков.

    P>> Как много программ

    P>> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
    P>> или UndefinedBehaviorException при new ?

    S>Почем я знаю? Лично мне такую возможность часто приходится учитывать.

    Лично вы под C++ ? Тока не надо быть меня ногами.
    Re[67]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 01.02.05 10:42
    Оценка:
    Hello, Poudy!
    You wrote on Tue, 01 Feb 2005 10:08:51 GMT:

    P> Ну это глупости на самом деле Программист почти всегда знает что и

    P> откуда, и при этом совсем не обязательно расставлять try/catch вокруг
    P> любого вызова.

    Знает, ага. Только часто забывает Да и вообще все развитие средств
    программирования направлено на то, чтобы объем необходимых знаний уменьшить,
    а где нельзя уменьшить — заменить глобальные знания деталей локальными.
    Потому что в голову все детали программы не помещаются.

    P>>> б — неужто приватные Hashtable могут

    P>>> кидать исключения и это составляет проблему?

    S>> При чем здесь Hashtable?

    P> Это в вопросу о том, что ты знаешь что может упать, а что нет.

    Ну вообще-то и приватные Hashtable упасть могут Особенно если физически
    размещены на другом компьютере, а приватными стали после того, как ссылку на
    них в конструктор передали.

    P>>> в — для удаленных объектов

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

    S>> Ага, можно. Зачем обертка, правда, мне непонятно — я ж твои мысли не

    S>> читаю.
    P> Обертка нужна
    P> — для получения сообщений о том, что она отвалилась, и изъятии её при
    P> этом из разных там коллекций. — для попыток переподключения.
    P> — для сохранения возможности вызвать некоторые свойства уже после того,
    P> как объект отвалился (например, кешированное Name или IsAlive = false)

    Там и так усе через обертки работает. А обертки параметризованы стратегиями.
    Впрочем, не о них речь.

    P> Под .Net можно, конечно, решить и без обертки — при помощи синков.

    А синки вместе с объектом не отвалятся?

    P>>> Как много программ

    P>>> на Java или C# закладываются на какой-нибудь NotEnougthMemoryException
    P>>> или UndefinedBehaviorException при new ?

    S>> Почем я знаю? Лично мне такую возможность часто приходится учитывать.

    P> Лично вы под C++ ? Тока не надо быть меня ногами.

    Надо, надо — за провокацию Естественно, я учитываю не мифические
    NotEnougthMemoryException и UndefinedBehaviorException, а вполне реальные
    std::bad_alloc и CMemoryException. Которые иногда даже и прилетают таки.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 01.02.05 12:11
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>2) Ни потоков, ни процессов в объектно ориентированных операционных системах не бывает. Вместо них в объектно ориентированных операционных системах бывают АКТИВНЫЕ ОБЪЕКТЫ. То есть прибиванию подлежит не процесс и не поток, а активный объект (obj := NIL).


    Сформулируем задачу так: можно ли устанавливать квоты на количество ресурсов (в первую очередь — на память), которым владеет данный активный объект?
    Если несколько активных объектов совместно владеют какой-то памятью (естественно, в типизированном виде) — то как трактовать это с т.з. квот?

    Собственно, зачем в виндоузе, юниксе и OS/360 сделано разделение на процессы: чтобы определить зоны ответственности. Менеджеру ресурсов глубоко фиолетово, сколько потоков (представленных активными объектами или банальными хэндлами) существуют в одном процессе, какие между ними зависимости и кто из них жрёт ресурсы. Весь процесс жрёт, и именно он как единое целое будет ограничен (прибит, перепланирован, функция запроса вернёт ошибку — это уже мелочи реализации).
    Перекуём баги на фичи!
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 01.02.05 12:18
    Оценка:
    Кодт пишет:

    > Собственно, зачем в виндоузе, юниксе и OS/360 сделано разделение на

    > процессы: чтобы определить зоны ответственности. Менеджеру ресурсов
    > глубоко фиолетово, сколько потоков (представленных активными объектами
    > или банальными хэндлами) существуют в одном процессе, какие между ними
    > зависимости и кто из них жрёт ресурсы. *Весь процесс* жрёт, и именно
    > он как единое целое будет ограничен (прибит, перепланирован, функция
    > запроса вернёт ошибку — это уже мелочи реализации).

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

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 01.02.05 12:30
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>В Си++ типизация сильнее, чем в Обероне?

    AVC>Это Вы баек о пользе шаблонов в Си++ наслушались?
    AVC>А как Вам конструкции вида
    AVC>
    AVC>int foo(void *p)
    AVC>{
    AVC>  return ((int (*)())p)();
    AVC>}
    AVC>


    Да, сильнее. По стандарту С++, конверсия между void* и void(*)() невозможна; другое дело, что некоторые компиляторы для некоторых платформ (одно из требований — это tiny|large|flat модель памяти) на это плюют.
    Перекуём баги на фичи!
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 01.02.05 12:42
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    WH>> Вот там они и сидят. В принципе они только и нужны для написания библиотек низкого уровня. Короче можешь считать что они спрятаны в нутрь компилятора.


    СГ>Если бы да кабы, то в носу бы выросли грибы.


    Кто-то здесь учил друг друга хорошим манерам

    WH>> Кстати а как на счет ошибок в компиляторе оберона?...


    СГ>ЧТО???????????????


    А почему бы и нет?

    Для С++ пишутся специальные библиотеки тестовых сырцов на все случаи жизни, и скармливаются компилятору. После чего выносится вердикт: "данный компилятор на N% совместим со Стандартом" (столько-то правильных файлов не распознал или породил неправильный код; столько-то заведомо ошибочных скомпилировал и не мяукнул).
    Да, С++ — язык сложный, в том числе сложный для компилятора. Поэтому придумать всеохватные тесты — это гиганский труд.
    Но существуют ли такие тесты для Оберонов? Кстати, трудоёмкость здесь будет вызвана большим количеством языков в семействе, обладающих к тому же разнородным синтаксисом. Это значит — опять копипаст и доводка напильником...
    Похоже, идиома копипаста довольно глубоко засела в язык, что даже сюда добралась.
    Перекуём баги на фичи!
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 01.02.05 12:52
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    AVC>>В Си++ типизация сильнее, чем в Обероне?

    AVC>>Это Вы баек о пользе шаблонов в Си++ наслушались?
    AVC>>А как Вам конструкции вида
    AVC>>
    AVC>>int foo(void *p)
    AVC>>{
    AVC>>  return ((int (*)())p)();
    AVC>>}
    AVC>>


    К>Да, сильнее. По стандарту С++, конверсия между void* и void(*)() невозможна; другое дело, что некоторые компиляторы для некоторых платформ (одно из требований — это tiny|large|flat модель памяти) на это плюют.


    Отстал, наверное, я от жизни.
    А что, стандарт Си++ и такие конструкции запрещает?
    union {
      void *p;
      void (*fp)();
    };


    P.S. Прошу прощения, если задерживаюсь с ответами на посты.
    То RSDN упадет, то работы навалом...
    Как освобожусь, постараюсь всем ответить.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 01.02.05 13:02
    Оценка:
    AVC пишет:

    > Отстал, наверное, я от жизни.

    > А что, стандарт Си++ и такие конструкции запрещает?
    >
    >union {
    > void *p;
    > void (*fp)();
    >};
    >
    >
    Нет, но тут программист сам виноват (явно пытается обойти ограничение).

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 07.02.05 12:24
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Отстал, наверное, я от жизни.

    >> А что, стандарт Си++ и такие конструкции запрещает?
    >>
    >>union {
    >> void *p;
    >> void (*fp)();
    >>};
    >>
    >>
    C>Нет, но тут программист сам виноват (явно пытается обойти ограничение).

    Допустим.
    Хотя кто-то тут утверждал, что в Си++ — "сильная типизация".
    Давай-те все-таки определимся в понятиях.
    А то, ИМХО, здесь путают "сильную" и "статическую" типизацию.
    Сильная типизация — это такая типизация, которую нельзя обойти.
    В Си++ такой типизации нет. Здесь столько путей ее обхода: и явное приведение указателей, и unionы, и т.д. и т.п.
    Если программист, использующий эти средства, "сам виноват", то зачем они присутствуют в языке? Чтобы потом все "списать" на программиста?
    Ну, хорошо. Пусть программист "сам виноват".
    Рассмотрим недавний трагикомический случай из практики.
    Тестируем новый процессор.
    Используемые в нем алгоритмы сначала были написаны на Си++ (программный эмулятор), а затем на VHDL.
    Дошло дело до тестирования команд с плавающей точкой.
    Надо "сгенерить" последовательность входных и выходных значений.
    "Генерим" — какая-то "фигня" получается.
    Все входные данные — одно и то же число.
    В чем дело? Оказывается, программист случайно (вместе с предыдущими строками) закомментировал оператор приведения operator float().
    Вот (схематично, конечно) как это произошло:
    #include <stdio.h>
    
    class Float {
        float _float;
    public:
        Float(float x) : _float(x) { }
    
        // следующая строка была закомментирована по ошибке (просто опечатка)
        //operator float() { return _float; }
    
        // в реальной программе bool() проверяет валидность Float
        operator bool() { return true; }
    };
    
    int main()
    {
        Float F = 3.1415926536f; // Кто и шутя, и скоро пожелаетъ Пи узнать число, ужъ знаетъ.
        float x = F;
        printf("%f\n", x); // Что напечаталось? Правильно, 1.000000
        return 0;
    }

    Все компиляторы Си++, используемые нами в работе, сгенерировали неявное приведение bool к float, даже не хрюкнув!
    Чудо, что за сильно типизированный язык!
    Не откажу себе в удовольствии процитировать авторов книги, содержащей астрономические алгоритмы на Си++.
    (Я имею в виду книгу Пфлегера и Монтенбрука "Астрономия на персональном компьютере".)

    Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

    Привожу, как говорится, без комментариев.
    Лишь замечу, что ни одного из этих недостатков нет у Оберона.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Offtopic
    От: Sergey J. A. Беларусь  
    Дата: 07.02.05 17:44
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC> Float F = 3.1415926536f; // Кто и шутя, и скоро пожелаетъ Пи узнать число, ужъ знаетъ.

    Мне больше нравиться
    'Это я знаю и помню прекрасно их многие знаки мне лишни напрасно'
    Я — свихнувшееся сознание Джо
    Re: Offtopic
    От: AVC Россия  
    Дата: 07.02.05 20:41
    Оценка:
    Здравствуйте, Sergey J. A., Вы писали:

    SJA>Здравствуйте, AVC, Вы писали:


    AVC>> Float F = 3.1415926536f; // Кто и шутя, и скоро пожелаетъ Пи узнать число, ужъ знаетъ.

    SJA>Мне больше нравиться
    SJA>'Это я знаю и помню прекрасно их многие знаки мне лишни напрасно'
    SJA>


    Применительно к float последние 2-3 цифры, конечно же, лишние.
    Просто хотелось "доцитировать" до точки.
    Вообще же, для запоминания числа Пи существует уйма стихов, иные из которых довольно длинные (двадцать цифр после точки ).
    Стишок "кто и шутя..." был, кажется, придуман нижегородским учителем Шенроком.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 07.02.05 22:56
    Оценка:
    Здравствуйте, AVC, Вы писали:

    []

    AVC>class Float {
    AVC>    float _float;
    AVC>public:
    AVC>    Float(float x) : _float(x) { }
    
    AVC>    // следующая строка была закомментирована по ошибке (просто опечатка)
    AVC>    //operator float() { return _float; }
    
    AVC>    // в реальной программе bool() проверяет валидность Float
    AVC>    operator bool() { return true; }
    AVC>}

    ну вы блин даете...
    А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 08.02.05 02:39
    Оценка:
    AVC,

    > А что, стандарт Си++ и такие конструкции запрещает?

    >
    > union {
    >   void *p;
    >   void (*fp)();
    > };
    >


    Конструкцию — нет. А (предполагаемое) использование, заключающееся в записи в p с последующим чтением из fp (или наоборот) — да. Правда, контролировать компилятору/среде исполнения не предписывает, просто снимает с себя ответственность за последствия дальнейшей работы соответствующей программы.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 08.02.05 05:55
    Оценка:
    Здравствуйте, AVC, Вы писали:
    [.....]
    AVC>Рассмотрим недавний трагикомический случай из практики.
    [.....]

    Внимательно прочитал. Откомпилировал программу. Вывела она единицу. Один пустячок: с точки зрения ОС программа отработала правильно, к теме обсуждения (защита памяти) недостаток языка C++ отношения не имеет. Это стоит обсудить где-нибудь в отдельной ветке.

    AVC>Не откажу себе в удовольствии процитировать авторов книги, содержащей астрономические алгоритмы на Си++.

    AVC>(Я имею в виду книгу Пфлегера и Монтенбрука "Астрономия на персональном компьютере".)
    AVC>

    AVC>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.


    Интересно. С удовольствием почитал бы. В такой книге может почерпнуть для себя даже очень далекий от астрономии человек.
    История создания книги, полагаю, такова. Авторы накопили определенный опыт в данной предметной области и решили рассказать о нем в форме, доступной простому смертному. В издательстве им сказали, что неплохо было бы программный код представить на C++, тираж бы поднялся. (Я абсолютно уверен, что астрономы всю математику писали на Фортране). Многие, переходя с Фортрана на C++, испытывают сильный дискомфорт.
    В Фортране тоже не выполняется проверка выхода за границы массива, но это никого не смущает — техника работы с массивами в Фортране отработана так, что на отсутствие проверок просто не обращают внимания. А в случае ошибки — сработает защита памяти. При переходе с Фортрана на C/C++ она действительно срабатывает слишком часто. Все дело в индексации: в Фортране она начинается с 1, в C/C++ — с 0.
    А многомерных массивов нет не только в C++.
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 09:39
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:
    AVC>>    // в реальной программе bool() проверяет валидность Float
    AVC>>    operator bool() { return true; }
    КЕ>

    КЕ> ну вы блин даете...
    КЕ>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

    Оказывается, специально для этого в С++ придуман workaround — возвращать тип, приводимый к bool, но ни к чему другому. Что-то вроде
    class Foo
    {
    public:
      typedef void (Foo::*some_bool)();
    private:
      void some_true() {}
    
    public:
      operator some_bool() const { if(...) return &Foo::some_true : 0; }
    
      ...
    };

    (Недавно было в форуме C++, да и в boost видел — но не помню точно, как он там называется).

    Вообще же, в ряде случаев имеет смысл делать внешние функции либо хотя бы по-человечески названные методы
    bool is_valid(double v); // проверка на NaN и Inf - встроенными средствами
    bool is_valid(float v);
    bool is_valid(const Float& v) { return v.is_valid(); }
    Перекуём баги на фичи!
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 12:14
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    AVC>>Рассмотрим недавний трагикомический случай из практики.

    P>Внимательно прочитал. Откомпилировал программу. Вывела она единицу. Один пустячок: с точки зрения ОС программа отработала правильно, к теме обсуждения (защита памяти) недостаток языка C++ отношения не имеет. Это стоит обсудить где-нибудь в отдельной ветке.

    Обсуждение языка и ОС Оберон у нас постоянно пересекаются.
    Ведь ОС Оберон основывается именно на свойствах одноименного языка.
    (Думаю, именно поэтому они носят одно и то же имя.)
    Тема же "сильной типизации Си++" была поднята не мной, а WolfHound.
    В чем я с ним, конечно, не согласен.

    AVC>>Не откажу себе в удовольствии процитировать авторов книги, содержащей астрономические алгоритмы на Си++.

    AVC>>(Я имею в виду книгу Пфлегера и Монтенбрука "Астрономия на персональном компьютере".)
    AVC>>

    AVC>>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

    P>Интересно. С удовольствием почитал бы. В такой книге может почерпнуть для себя даже очень далекий от астрономии человек.

    Книга выпущена в 2002 году издательством "Питер".
    http://shop.piter.com/book_about.phtml?id=978531800223&amp;web_ok=
    Правда, говорят, что найти ее в продаже уже не так просто.

    P>История создания книги, полагаю, такова. Авторы накопили определенный опыт в данной предметной области и решили рассказать о нем в форме, доступной простому смертному. В издательстве им сказали, что неплохо было бы программный код представить на C++, тираж бы поднялся. (Я абсолютно уверен, что астрономы всю математику писали на Фортране). Многие, переходя с Фортрана на C++, испытывают сильный дискомфорт.


    Полную историю книги не знаю.
    Знаю только, что предыдущее издание книги содержало программы на Паскале.
    Отсюда, видимо, и некоторое разочарование авторов в Си++.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 08.02.05 12:40
    Оценка:
    AVC пишет:

    > C>Нет, но тут программист сам виноват (явно пытается обойти ограничение).

    > Допустим.
    > Хотя кто-то тут утверждал, что в Си++ — "сильная типизация".
    > Давай-те все-таки определимся в понятиях.
    > А то, ИМХО, здесь путают "сильную" и "статическую" типизацию.
    > *Сильная* типизация — это такая типизация, которую *нельзя* обойти.

    Нет. Сильную типизацию нельзя обойти НЕЯВНО.

    А руками _заставить_ привести — очень даже и можно ...

    > В Си++ такой типизации нет. Здесь столько путей ее обхода: и явное

    > приведение указателей, и *union*ы, и т.д. и т.п.
    > Если программист, использующий эти средства, "сам виноват", то зачем
    > они присутствуют в языке?

    Затем, что иногда бывают полезны для других целей. Классический пример:
    union BIGINT
    {
        struct Ints
        {
            int i1,i2;
        };
        struct Bytes
       {
            byte b1,b2,b3,b4,b5,b6,b7,b8;
        };
    }


    > Используемые в нем алгоритмы сначала были написаны на Си++

    > (программный эмулятор), а затем на VHDL.
    > *Все* компиляторы Си++, используемые нами в работе, сгенерировали
    > *неявное* приведение bool к float, даже не хрюкнув!

    Есть такая проблема — все дело в том, что bool был добавлен в язык очень
    поздно. Кстати, MSVC на такой код выдает предупреждение.

    > Чудо, что за *сильно типизированный язык*!


    А он вполне сильно типизирован. И преобразование bool->float вполне себе
    валидно.

    > Не откажу себе в удовольствии процитировать авторов книги, содержащей

    > астрономические алгоритмы на Си++.
    > (Я имею в виду книгу Пфлегера и Монтенбрука "Астрономия на
    > персональном компьютере".)
    > Здесь надо сказать, что по сравнению с другими языками C++ имеет много
    > недостатков, которые затрудняют разработку сложных научных программ. В
    > частности, у него слабая поддержка одномерных и многомерных массивов,
    > нет локальных процедур, неудачная концепция модуля, не поддерживается
    > проверка индексов массивов, а также выполняется неконтролируемое
    > преобразование типов.

    Да, да, конечно же. Всякие uBlas, и т.п. — все полная фигня.

    И еще С++ неприспособлен для векторных вычислений, о чем наглядно
    свидетельствует http://www.pixelglow.com/macstl/
    И для параллельного программирования тоже не приспособлен, так как
    документа http://www.openmp.org/drupal/mp-documents/cspec20_bars.pdf нет
    в природе.

    > Привожу, как говорится, без комментариев.

    > Лишь замечу, что ни одного из этих недостатков нет у Оберона.

    У этого уродца вообще ничего нет.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 08.02.05 12:54
    Оценка:
    Hello, Cyberax!
    You wrote on Tue, 08 Feb 2005 12:40:32 GMT:

    C>>> Нет, но тут программист сам виноват (явно пытается обойти

    C>>> ограничение).
    ??>> Допустим.
    ??>> Хотя кто-то тут утверждал, что в Си++ — "сильная типизация".
    ??>> Давай-те все-таки определимся в понятиях.
    ??>> А то, ИМХО, здесь путают "сильную" и "статическую" типизацию.
    ??>> *Сильная* типизация — это такая типизация, которую *нельзя* обойти.

    C> Нет. Сильную типизацию нельзя обойти НЕЯВНО.


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

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 13:11
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:

    КЕ> ну вы блин даете...

    КЕ>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

    Видно, возмущение было столь сильным, что на критику уже слов не хватило?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[38]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 13:54
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:


    >> *Сильная* типизация — это такая типизация, которую *нельзя* обойти.

    C>Нет. Сильную типизацию нельзя обойти НЕЯВНО.
    C>А руками _заставить_ привести — очень даже и можно ...

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

    >> В Си++ такой типизации нет. Здесь столько путей ее обхода: и явное

    >> приведение указателей, и *union*ы, и т.д. и т.п.
    >> Если программист, использующий эти средства, "сам виноват", то зачем
    >> они присутствуют в языке?

    C>Затем, что иногда бывают полезны для других целей. Классический пример:

    C>
    C>union BIGINT
    C>{
    C>    struct Ints
    C>    {
    C>        int i1,i2;
    C>    };
    C>    struct Bytes
    C>   {
    C>        byte b1,b2,b3,b4,b5,b6,b7,b8;
    C>    };
    C>}
    C>


    О чем я и говорил: сильной типизации в Си++ нет.

    >> Используемые в нем алгоритмы сначала были написаны на Си++

    >> (программный эмулятор), а затем на VHDL.
    >> *Все* компиляторы Си++, используемые нами в работе, сгенерировали
    >> *неявное* приведение bool к float, даже не хрюкнув!
    C>Есть такая проблема — все дело в том, что bool был добавлен в язык очень
    C>поздно. Кстати, MSVC на такой код выдает предупреждение.

    Еще раз проверил на MSVC. Опять без warningов.

    >> Чудо, что за *сильно типизированный язык*!

    C>А он вполне сильно типизирован. И преобразование bool->float вполне себе
    C>валидно.

    Правда?!
    А вот мне, дурню, кажется, что между bool и float нет ничего общего.
    Поэтому и неявное преобразование недопустимо.

    >> Не откажу себе в удовольствии процитировать авторов книги, содержащей

    >> астрономические алгоритмы на Си++.
    >> (Я имею в виду книгу Пфлегера и Монтенбрука "Астрономия на
    >> персональном компьютере".)
    >> Здесь надо сказать, что по сравнению с другими языками C++ имеет много
    >> недостатков, которые затрудняют разработку сложных научных программ. В
    >> частности, у него слабая поддержка одномерных и многомерных массивов,
    >> нет локальных процедур, неудачная концепция модуля, не поддерживается
    >> проверка индексов массивов, а также выполняется неконтролируемое
    >> преобразование типов.
    C>Да, да, конечно же. Всякие uBlas, и т.п. — все полная фигня.
    C>И еще С++ неприспособлен для векторных вычислений, о чем наглядно
    C>свидетельствует http://www.pixelglow.com/macstl/
    C>И для параллельного программирования тоже не приспособлен, так как
    C>документа http://www.openmp.org/drupal/mp-documents/cspec20_bars.pdf нет
    C>в природе.

    Подождите.
    Ведь в приведенной мной цитате все правда.
    Многомерных массивов нет.
    Модулей нет.
    Индексы — если и можно контролировать, то только в отдельных случаях.
    Пример неконтролируемого приведения типов я только что привел.
    Если Вы с этими утверждениями не согласны, то оспорьте их.
    А существование где-то там пары навороченных библиотек не имеет к данному вопросу никакого отношения.

    >> Привожу, как говорится, без комментариев.

    >> Лишь замечу, что ни одного из этих недостатков нет у Оберона.
    C>У этого уродца вообще ничего нет.

    Я так понял, что разумные аргументы закончились?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 13:58
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Многомерных массивов нет.


    Конечно, я имел в виду: гибких многомерных массивов.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 08.02.05 14:27
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Обсуждение языка и ОС Оберон у нас постоянно пересекаются.

    AVC>Ведь ОС Оберон основывается именно на свойствах одноименного языка.

    И это приводит к неслабой путанице. Особенно если учесть, что в руководстве по Оберону сказано: среда не является частью языка, однако до некоторой степени подразумевается при определении языка.

    AVC>Полную историю книги не знаю.

    AVC>Знаю только, что предыдущее издание книги содержало программы на Паскале.
    AVC>Отсюда, видимо, и некоторое разочарование авторов в Си++.

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

    Действительно, язык мог быть и Паскаль, там упоминается о локальных процедурах. Меня смутило заявление о многомерных массивах, которые, кроме Фортрана, нигде не существуют, а организованы с помощью массивов меньших размерностей.

    А вообще-то дискуссия перерастает в треп, скоро кулаки рисовать будут (или еще что-нибудь). Неприятно, когда отсутствие аргументов заменяется разбрасыванием минусов или, что хуже, личными нападками или репликами типа "сам такой".
    Re[2]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 08.02.05 14:32
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К> Пусть некий активный объект владеет стеком своего потока


    Э-э-э, бывает либо одно либо другое:

    1) Обычная (не объектно ориентированная) ОСь с процессами/потоками.
    2) Активные объекты как основа построения полностью объектно ориентированной ОСи.

    Там где есть процессы/потоки — там нет активных объектов, и наоборот.

    Все дело в той штуковине, которая разруливает параллельные активности.
    В одном случае она одна, в другом — совсем другая.
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 08.02.05 14:38
    Оценка:
    AVC,

    > C> Кстати, MSVC на такой код выдает предупреждение.


    > Еще раз проверил на MSVC. Опять без warningов.


    /Wall ?
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 14:47
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> Еще раз проверил на MSVC. Опять без warningов.

    ПК>/Wall ?

    командная строка:

    cl /W4 /WX bool2float.cpp


    Ни warningа, ни ошибки компиляции.
    Наверное, версия компилятора устарела (MSVC 6.0)?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[3]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 14:57
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    К>> Пусть некий активный объект владеет стеком своего потока


    СГ>Э-э-э, бывает либо одно либо другое:


    СГ>1) Обычная (не объектно ориентированная) ОСь с процессами/потоками.

    СГ>2) Активные объекты как основа построения полностью объектно ориентированной ОСи.

    СГ>Там где есть процессы/потоки — там нет активных объектов, и наоборот.


    СГ>Все дело в той штуковине, которая разруливает параллельные активности.

    СГ>В одном случае она одна, в другом — совсем другая.

    Развей моё невежество, пожалуйста.
    Мне кажется, что понятие "стек" и "поток" — более широки, чем поддержанные аппаратно простейшие реализации того и другого.
    Если рассматривать активный объект как сущность, чьё текущее состояние описывается LIFO-цепочкой (т.е. стеком) фреймов, а поведение тактируется неким произвольным источником (внутренним или внешним, event-driven) — то принципиально ничего не поменялось.
    Перекуём баги на фичи!
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 15:00
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    AVC>>Обсуждение языка и ОС Оберон у нас постоянно пересекаются.

    AVC>>Ведь ОС Оберон основывается именно на свойствах одноименного языка.
    P>И это приводит к неслабой путанице. Особенно если учесть, что в руководстве по Оберону сказано: среда не является частью языка, однако до некоторой степени подразумевается при определении языка.

    Возможно.
    Я и сам задавал себе вопрос, почему используется одно и то же имя.
    (Не как с Модулой-2: там были Modula-2 и Lilith соответственно.)
    Единственное, что пришло в голову: система очень "завязана" на язык.
    Обратное не верно. Язык может использоваться и в другой среде.

    P>К сожалению, на сайте издательства сказано, что книга больше не продается. Все равно спасибо за ссылку.


    Увы...
    Поискал через
    http://www.booksearch.ru
    Никто не отозвался.
    Может, переиздадут?

    P>Действительно, язык мог быть и Паскаль, там упоминается о локальных процедурах. Меня смутило заявление о многомерных массивах, которые, кроме Фортрана, нигде не существуют, а организованы с помощью массивов меньших размерностей.


    Это место я пока не понял.
    В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

    P>А вообще-то дискуссия перерастает в треп, скоро кулаки рисовать будут (или еще что-нибудь). Неприятно, когда отсутствие аргументов заменяется разбрасыванием минусов или, что хуже, личными нападками или репликами типа "сам такой".


    И это очень жаль...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 08.02.05 15:05
    Оценка:
    AVC пишет:

    >>> *Сильная* типизация — это такая типизация, которую *нельзя* обойти.

    > C>Нет. Сильную типизацию нельзя обойти НЕЯВНО.
    > C>А руками _заставить_ привести — очень даже и можно ...
    > В том-то и проблема, что в Си++ нельзя отличить программы, в которых
    > было использовано такое "приведение руками", от программ, в которых
    > такого приведения не было.

    Да, но есть средства (namspace'ы, например), позволяющие избежать многих
    проблем со сторонним кодом.

    > C>Затем, что иногда бывают полезны для других целей. Классический пример:

    > C>
    >
    >C>union BIGINT
    >C>{
    >C> struct Ints
    >C> {
    >C> int i1,i2;
    >C> };
    >C> struct Bytes
    >C> {
    >C> byte b1,b2,b3,b4,b5,b6,b7,b8;
    >C> };
    >C>}
    >C>
    >
    >
    > О чем я и говорил: сильной типизации в Си++ нет.

    Есть. Типу BIGINT присвоить int не получится, просто у типа семантика
    BIGINT несколько отличается от обычной структуры.

    >>> Используемые в нем алгоритмы сначала были написаны на Си++



    > C>Есть такая проблема — все дело в том, что bool был добавлен в язык

    > очень
    > C>поздно. Кстати, MSVC на такой код выдает предупреждение.
    > Еще раз проверил на MSVC. Опять без *warning*ов.

    Какой уровень предупреждений?

    >>> Чудо, что за *сильно типизированный язык*!

    > C>А он вполне сильно типизирован. И преобразование bool->float вполне
    > себе
    > C>валидно.
    > Правда?!
    > А вот мне, дурню, кажется, что между bool и float нет *ничего общего*.
    > Поэтому и *неявное* преобразование *недопустимо*.

    Это уже другой вопрос — неявное приведение типов. Тут как обычно: С++
    дает достаточно веревки чтобы повеситься.

    > C>Да, да, конечно же. Всякие uBlas, и т.п. — все полная фигня.

    > C>И еще С++ неприспособлен для векторных вычислений, о чем наглядно
    > C>свидетельствует http://www.pixelglow.com/macstl/
    > C>И для параллельного программирования тоже не приспособлен, так как
    > C>документа http://www.openmp.org/drupal/mp-documents/cspec20_bars.pdf
    > нет
    > C>в природе.
    > Подождите.
    > Ведь в приведенной мной цитате *все правда*.
    > Многомерных массивов нет.

    boost::multi_array.

    > Модулей нет.


    Есть. Например, в виде COM.

    > Индексы — если и можно контролировать, то только в отдельных случаях.


    Для каждого отдельного случая — есть.

    > А существование где-то там пары навороченных библиотек не имеет к

    > данному вопросу никакого отношения.

    Отношение имеет то, что ЯЗЫК позволяет их организовать — этим С++ и
    уникален, он позволяет делать практически все. А вот в Обероне как ни
    старайся, но типизированные коллекции в общем виде не сделать. И не надо
    говорить, что они не нужны.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[3]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 08.02.05 15:08
    Оценка:
    Сергей Губанов пишет:

    > Там где есть процессы/потоки — там нет активных объектов, и наоборот.


    Ваш "активный объект" — это и есть поток.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 08.02.05 15:12
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Увы... :(

    AVC>Поискал через
    AVC>http://www.booksearch.ru
    AVC>Никто не отозвался.
    AVC>Может, переиздадут?

    Хорошо бы. Ладно, потерпим...

    AVC>Это место я пока не понял.

    AVC>В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

      ARRAY L0, L1, ..., Ln OF T

    понимается как сокращение:

       ARRAY L0 OF
         ARRAY L1 OF
         ...
            ARRAY Ln OF T

    (из руководства по языку Оберон).
    T — это "настоящий" многомерный массив или он определен так же, как в C++, через одномерные?

    До C# еще не дошел, не всегда волен выбирать себе инструмент для работы.
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 17:03
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:


    >> В том-то и проблема, что в Си++ нельзя отличить программы, в которых

    >> было использовано такое "приведение руками", от программ, в которых
    >> такого приведения не было.
    C>Да, но есть средства (namspace'ы, например), позволяющие избежать многих
    C>проблем со сторонним кодом.

    Каким образом?

    >> C>поздно. Кстати, MSVC на такой код выдает предупреждение.

    >> Еще раз проверил на MSVC. Опять без *warning*ов.
    C>Какой уровень предупреждений?

    Максимальный для моего компилятора (MSVC 6.0).
    Командная строка:

    cl /W4 /WX bool2float.cpp


    >> А вот мне, дурню, кажется, что между bool и float нет *ничего общего*.

    >> Поэтому и *неявное* преобразование *недопустимо*.
    C>Это уже другой вопрос — неявное приведение типов. Тут как обычно: С++
    C>дает достаточно веревки чтобы повеситься.

    Я не "ругаю" Си++ "вообще". (Самому на нем приходится писать.)
    Я только утверждаю, что он не является сильно типизированным, простым и надежным.
    Скажу прямо, я считаю эти свои утверждения очевидными, и не могу понять несогласия в данных пунктах.

    >> Многомерных массивов нет.

    C>boost::multi_array.

    Гибких (что я забыл упомянуть в первый раз ) многомерных массивов в языке Си++ нет.
    А библиотечная поддержка и в Visual Basic может быть.

    >> Модулей нет.

    C>Есть. Например, в виде COM.

    Опять же, COM — не часть языка Си++.

    >> Индексы — если и можно контролировать, то только в отдельных случаях.

    C>Для каждого отдельного случая — есть.

    Вот это и есть путь PL/1 — "для каждого отдельного случая".

    >> А существование где-то там пары навороченных библиотек не имеет к

    >> данному вопросу никакого отношения.
    C>Отношение имеет то, что ЯЗЫК позволяет их организовать — этим С++ и
    C>уникален, он позволяет делать практически все. А вот в Обероне как ни
    C>старайся, но типизированные коллекции в общем виде не сделать. И не надо
    C>говорить, что они не нужны.

    Вас послушать, в других языках библиотеки просто невозможны.
    В Обероне легко (кстати, даже легче, чем в Си++: нет проблем с удалением объектов кучи) можно сделать универсальные контейнеры, те же хэш-таблицы. Там, правда, есть проблема с ковариантностью.
    Я это признал давно, когда еще Павел Кузнецов об этом написал (несколько месяцев назад). (Признал именно потому, что сам имею привычки Си++ного программиста. На самом деле, никакого ущерба обероновским программистам это не причиняет.)
    Единственное, в чем я с ним не согласился, так это в том, что следствием будет долгая и трудная отладка.
    Просто в Обероне иначе решается вопрос типизации.

    Как мне кажется, обсуждение типизации в Си++ потихоньку перерастает во флейм.
    Сторонники Си++ предпочитают вообще не видеть проблем своего любимого (и ради Бога!) языка. Главная же проблема — что Си++ сам становится проблемой. Такое чувство, что его уже никто (кроме Страуструпа и Павла Кузнецова ) полностью и не знает.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 17:13
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    AVC>>Это место я пока не понял.

    AVC>>В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

    P>
    P>  ARRAY L0, L1, ..., Ln OF T
    P>

    P>понимается как сокращение:
    P>
    P>   ARRAY L0 OF
    P>     ARRAY L1 OF
    P>     ...
    P>        ARRAY Ln OF T
    P>

    P>(из руководства по языку Оберон).
    P>T — это "настоящий" многомерный массив или он определен так же, как в C++, через одномерные?

    Гм.
    Честно говоря, и сейчас не понял.
    Память подсказывает, что в Фортране линеаризация была по столбцам, а не по строкам, как в других языках. Других особенностей что-то не припомню.
    На всякий случай, расскажу еще раз, что когда-то был приятно удивлен, узнав, что матрицы в Обероне могут иметь произвольное число столбцов, в отличие от Си, Си++ и Паскаля.
    Например:
    TYPE Matrix = ARRAY OF ARRAY OF REAL;

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 17:19
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    КЕ>>> ну вы блин даете...

    КЕ>>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?
    AVC>>Видно, возмущение было столь сильным, что на критику уже слов не хватило?

    К>На самом деле, возмущение справедливое.


    Прошу прощения, что задерживаюсь с ответом.
    Не успеваю...
    У Вас именно аргументация, хочется вникнуть.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 08.02.05 17:38
    Оценка:
    К>4) Наконец, компилятор VC даёт предупреждение о приведении к bool и из bool в число. (Про другие компиляторы — врать не буду). Кому хочется развлечений — включайте опцию "treat warnings as errors" и наслаждайтесь.

    Здесь я погнал. bool в число перевести — как нефиг делать. false==0, true==1.
    Здесь он от enum Bool {False,True} не отличается.

    И, в ряде случаев, это фича.
    Перекуём баги на фичи!
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 08.02.05 21:52
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    КЕ>>> ну вы блин даете...

    КЕ>>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?
    AVC>>Видно, возмущение было столь сильным, что на критику уже слов не хватило?
    К>На самом деле, возмущение справедливое.

    Подумал я и... в чем-то согласился.
    Действительно, возмущение (отчасти) справедливое.
    Сейчас попробую восстановить по шагам, как все случилось.
    (Опускаю малосущественные детали.)

    К>2) Практика показывает, что приведение к bool носит двоякий характер:

    К>* по смыслу — проверка валидности, непустоты и т.п.
    К>* по форме — сравнение с нулём.
    К>В случае числовых типов сравнение с нулём обычно определено; поэтому вводить дополнительно operator bool(), несущий иной смысл — это рассогласовывать форму и содержание.

    1) В тот момент, когда выяснилось, что происходит неявное преобразование bool к float, мы все находились в состоянии большой спешки. (В 21.00 нас с позором изгоняет охрана. ) Поэтому, когда выяснилось, что все дело в закомментированном операторе float(), я его самолично раскомментировал, и мы с помпой получили требуемый тестовый набор. После чего поспешили к VHDL-симулятору.
    2) Удаляя "//", я успел краем глаза заметить, что в операторе bool() происходит выделение экспоненты из битового представления "флота" с помощью
    & 0x7f800000
    . Если кто помнит битовое представление float, тот сразу "смекнет", что здесь анализируется экспонента. Я (на свою беду) помнил, т.к. в свое время была у нас маленькая проблема с "ужатием" float без потери действительно значимых цифр. (Требовалось передавать данные измерений в очень коротком пакете.)
    3) Вижу я, значит, выделение экспоненты и машинально про себя думаю: "Зачем это может быть в операторе bool()?"
    Не иначе, для проверки валидности "флота". (Если все биты экспоненты выставлены в единицу, то у нас или INFINITY, или NaN.) Так у меня и отложилось в сознании, и так я и написал в комментарии к bool(), когда излагал схему "происшествия" в своем посте.
    4) Сейчас заглянул в код повторно и вижу: экспонента-то сравнивается с нулем.
    Т.е. в действительности происходит рядовая проверка на 0, а не на "валидность" (не INFINITY и не NaN).
    Если экспонента равна 0, то число всегда 0 (возможно, со знаком: +0 или -0).
    Что тут скажешь? Опять старый лопух дезинформировал общественность!
    По сути дела, я осознал, что был не вполне прав, когда внушал Cyberax'у, что между bool и float нет ничего общего.
    Это общее есть, и это общее — (дурацкая, все-таки, прости Господи! не могу больше молчать! ) манера писать на Си выражения вида if (x) для произвольного типа.
    В нормальных языках пишут что-то вроде
    if (x != 0.0)

    или
    if (p != NULL)

    и т.п.

    К>В случае с Float — нужен ли был этот оператор, или просто руки шаловливые оказались?


    Все зависит от реализованных алгоритмов.
    Если при нулевой экспоненте возможна ненулевая мантисса, то оператор нужен.
    Т.к. обычное сравнение
    if (x)
    уже не сработает правильно.
    В противном случае — "шаловливые ручки".
    Но это вряд ли. Раньше этого оператора там не было (я точно помню), и вряд ли он появился там "для красоты".

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 08.02.05 23:10
    Оценка:
    Здравствуйте, AVC, Вы писали:

    КЕ>> ну вы блин даете...

    КЕ>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

    AVC>Видно, возмущение было столь сильным, что на критику уже слов не хватило?


    Скорее удивление, сорри что не пояснил. Ты только что говорил о неявных приведениях в cpp как о зле (и я согласен), но приводишь пример, увеличивающий это самое зло.

    Приведение float к bool возвращает false для 0.0 и true для остальных значений. А класс Float неявно приводится к float, и в то же время неявно приводится к bool, но по каким-то своим законам, отличным от float. Это никак не добавляет понятности в программу. Лучше ввести функцию is_valid() или типа того.
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 08.02.05 23:11
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Здравствуйте, Костя Ещенко, Вы писали:

    К>
    AVC>>>    // в реальной программе bool() проверяет валидность Float
    AVC>>>    operator bool() { return true; }
    КЕ>>

    КЕ>> ну вы блин даете...
    КЕ>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

    К>Оказывается, специально для этого в С++ придуман workaround — возвращать тип, приводимый к bool, но ни к чему другому. Что-то вроде

    К>
    К>class Foo
    К>{
    К>public:
    К>  typedef void (Foo::*some_bool)();
    К>private:
    К>  void some_true() {}
    
    К>public:
    К>  operator some_bool() const { if(...) return &Foo::some_true : 0; }
    
    К>  ...
    К>};
    К>

    К>(Недавно было в форуме C++, да и в boost видел — но не помню точно, как он там называется).

    Это мне известно. Но даже если сделать так, тип Float из примера AVC будет приводиться к bool совсем по иным правилам, нежели float, что не есть хорошо.

    К>Вообще же, в ряде случаев имеет смысл делать внешние функции либо хотя бы по-человечески названные методы

    К>
    К>bool is_valid(double v); // проверка на NaN и Inf - встроенными средствами
    К>bool is_valid(float v);
    К>bool is_valid(const Float& v) { return v.is_valid(); }
    К>


    Полностью согласен.
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 09.02.05 05:09
    Оценка:
    Здравствуйте, Кодт, Вы писали:

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

    К>Унифицированный интерфейс позволяет применять к разным реализациям одни алгоритмы.
    К>А если какое-то представление оказалось зашито в язык, то оно ставит остальные в неравные условия перед разработчиком алгоритмов.
    Именно это мы и наблюдаем [пока что] в NET: Многомерные массивы в C# &mdash; очередной наезд
    Автор: McSeem2
    Дата: 14.01.05
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[56]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 09.02.05 06:08
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон.


    Все собирался спросить, а что будет, если пользователь захочет заменить загруженную в память версию модуля более свежей? Не ждать же, пока сборщик мусора выгрузит этот модуль.
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 09.02.05 11:42
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Все зависит от реализованных алгоритмов.

    AVC>Если при нулевой экспоненте возможна ненулевая мантисса, то оператор нужен.
    AVC>Т.к. обычное сравнение
    if (x)
    уже не сработает правильно.

    AVC>В противном случае — "шаловливые ручки".
    AVC>Но это вряд ли. Раньше этого оператора там не было (я точно помню), и вряд ли он появился там "для красоты".

    Погоди! При нулевой экспоненте очень даже возможна ненулевая мантисса, а как же иначе!
    Вот при нулевой мантиссе ненулевая экспонента — это уже интереснее.
    Перекуём баги на фичи!
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 09.02.05 13:00
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>>4) Наконец, компилятор VC даёт предупреждение о приведении к bool и из bool в число. (Про другие компиляторы — врать не буду). Кому хочется развлечений — включайте опцию "treat warnings as errors" и наслаждайтесь.


    К>Здесь я погнал. bool в число перевести — как нефиг делать. false==0, true==1.

    К>Здесь он от enum Bool {False,True} не отличается.

    К>И, в ряде случаев, это фича.

    Не везде. Так как true= !false то если расматиривать как безнаковые числа, абстрагируясь от битовых и логических операторов то для байта это будет 255.
    WordBoоl дает честную -1, при приведении к инту
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 13:04
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    P>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Весь смысл модульной системы как раз в том и состоит что модуль есть синглетон.


    P>Все собирался спросить, а что будет, если пользователь захочет заменить загруженную в память версию модуля более свежей? Не ждать же, пока сборщик мусора выгрузит этот модуль.


    У Вас путаница в голове. Сборщик мусора работает с памятью, а к модулям он никакого отношения не имеет. К модулям имеет отношение динамический загрузчик. Чтобы выгрузить загруженный ранее модуль нужно явно дать определенную команду. Например, в BlackBox модуль выгружается вызовом процедуры Kernel.UnloadMod(mod: Module); Впрочем, если этот модуль в данный момент используется другими модулями, то эта процедура ничего не делает.
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 13:06
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Погоди! При нулевой экспоненте очень даже возможна ненулевая мантисса, а как же иначе!


    Я имел в виду что-то вроде:
    #include <stdio.h>
    
    int main()
    {
        float x;
        int *p = (int *) &x;
    
        *p = 0x007fffff;
        printf("%.15f %c= zero\n", x, (x) ? '!' : '=');
        return 0;
    }



    К>Вот при нулевой мантиссе ненулевая экспонента — это уже интереснее.


    Например, INFINITY.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 13:32
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:

    КЕ>Здравствуйте, AVC, Вы писали:


    AVC>>Видно, возмущение было столь сильным, что на критику уже слов не хватило?

    КЕ>Скорее удивление, сорри что не пояснил. Ты только что говорил о неявных приведениях в cpp как о зле (и я согласен), но приводишь пример, увеличивающий это самое зло.

    Я уже покаялся за дезинформацию...
    В действительности bool() делал проверку именно на нуль, как и положено в Си/Си++.
    Это, конечно, не изменяет моей точки зрения, что неявное преобразование bool во float недопустимо по соображениям здравого смысла.

    КЕ>Приведение float к bool возвращает false для 0.0 и true для остальных значений. А класс Float неявно приводится к float, и в то же время неявно приводится к bool, но по каким-то своим законам, отличным от float. Это никак не добавляет понятности в программу. Лучше ввести функцию is_valid() или типа того.


    Совершенно согласен.
    Тем более, что в Обероне только так и делают.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 09.02.05 13:32
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    К>>Здесь он от enum Bool {False,True} не отличается.


    К>>И, в ряде случаев, это фича.

    S> Не везде. Так как true= !false то если расматиривать как безнаковые числа, абстрагируясь от битовых и логических операторов то для байта это будет 255.
    S> WordBoоl дает честную -1, при приведении к инту

    Не надо смешивать. В Стандарте С++ прописано, что true=1. То же самое будет, если сделать через enum.

    WordBool и прочая шняга пришла из VB/VBA, где "истина" — это байт или ворд, забитый единичками.
    Между прочим, если x ненулевое, то ~x не обязательно нулевое Так что абстрагироваться от битовых/логических операторов нельзя.
    Перекуём баги на фичи!
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 13:35
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К> Кстати, а это именно прямоугольник, или массив с рваным краем (jagged array) ?


    В Обероне, в отличие от Java и от C#, массивы есть всякие.

    Есть и те, которые (гипер)прямоугольные и те которые с разной длиной на каждую размерность. Соответственно есть массивы обычные (настоящие, статические) которые располагаются на стеке или прямо внутри объекта, а есть и ссылочные-динамические.

    Например, можно объявить процедуру:
        PROCEDURE Calculate (VAR mat: ARRAY OF ARRAY OF REAL);
            VAR dim0, dim1, i, j: INTEGER;
        BEGIN
            dim0 := LEN(mat, 0);
            dim1 := LEN(mat, 1);
            FOR i := 0 TO dim0-1 DO
                FOR j := 0 TO dim1-1 DO
                    mat[i, j] := 0.0;
                END
            END
        END Calculate;


    а потом скормить ей


        PROCEDURE Test (  );
            VAR 
            a: ARRAY 192, 256 OF REAL; (* Статический массив расположенный на стеке *)
            b: POINTER TO ARRAY 4096, 1024 OF REAL; (* массив с заданными размерами находящийся в куче *)
            c: POINTER TO ARRAY OF ARRAY OF REAL; (* прямойгольный массив с заранее не известными размерами *)
        BEGIN
            Calculate(a);
            
            NEW(b);
            Calculate(b);
            
            NEW(c, 8128, 512);
            Calculate(c);
            
        END Test;



    Еще, естественно, можно работать с такими массивами mat: POINTER TO ARRAY OF POINTER TO ARRAY OF REAL — у него вторая размерность может быть разной в зависимости от "номера первой"... но такой массив в указанную выше Calculate уже передать нельзя (она принимает только прямоугольные). С таким массивом, естественно, надо будет работать так:
    FOR i := 0 TO LEN(mat) DO
      FOR j := 0 TO LEN(mat[i]) DO
        mat[i, j] := 0.0;
      END
    END
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 13:39
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC> ...Там, правда, есть проблема с ковариантностью...


    В языке Component Pascal ковариантность есть!
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 13:48
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    AVC>> ...Там, правда, есть проблема с ковариантностью...

    СГ>В языке Component Pascal ковариантность есть!

    Да, действительно есть.
    Насколько я помню, результат процедуры-функции может быть ковариантным.
    Но я еще не продумал следствия, вытекающие из этого.
    Можно ли, используя это свойство, обеспечить статический контроль типов в контейнерах, что в Си++ делается с помощью шаблонов?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 09.02.05 13:52
    Оценка:
    AVC wrote:

    > КЕ>Приведение float к bool возвращает false для 0.0 и true для остальных значений. А класс Float неявно приводится к float, и в то же время неявно приводится к bool, но по каким-то своим законам, отличным от float. Это никак не добавляет понятности в программу. Лучше ввести функцию is_valid() или типа того.

    >
    > Совершенно согласен.
    > Тем более, что в Обероне только так и делают.

    На всякий случай поясню свою точку зрения. Вне зависимости от того как работает operator bool(), лучше вообще его не вводить, в C++ "хватает" преобразования к float.
    Posted via RSDN NNTP Server 1.9
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[2]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 13:54
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>...Теперь достаточно в одной из функций подцепить указатель на сам объект и уйти в бесконечность.


    Все гораздо проще.
    Объекту вполне достаточно по своей воле не прекращать своей собственной активности хоть до бесконечности и он не будет никогда удален.

    Рантайм система языка Active Oberon гарантирует, что сборщик мусора не будет удалять объект до тех пор пока он активный. После того как объект перестает быть активным, вот тогда сборщик мусора может его удалить если конечно на него нет ссылок. Ну это и понятно. Ведь когда объект активен, то по крайней мере одна ссылка-то на него всегда есть — ведь стоит же он в очереди за процессорным временем (своим time slice). Когда он перестает быть активным, то есть в очереди за процессорным временем он больше не стоит — по его душу придет GC и сделает свое дело.

    Вывод — чтобы изничтожить неугодный активный объект достаточно убрать его из очереди за процессорным временем.
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 09.02.05 13:55
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Здравствуйте, Serginio1, Вы писали:


    К>>>Здесь он от enum Bool {False,True} не отличается.


    К>>>И, в ряде случаев, это фича.

    S>> Не везде. Так как true= !false то если расматиривать как безнаковые числа, абстрагируясь от битовых и логических операторов то для байта это будет 255.
    S>> WordBoоl дает честную -1, при приведении к инту

    К>Не надо смешивать. В Стандарте С++ прописано, что true=1. То же самое будет, если сделать через enum.


    К>WordBool и прочая шняга пришла из VB/VBA, где "истина" — это байт или ворд, забитый единичками.

    К>Между прочим, если x ненулевое, то ~x не обязательно нулевое Так что абстрагироваться от битовых/логических операторов нельзя.

    С точки зрения С++, а вот с точки зрения Delphi и OLE нормально. Мне лично больше нравится
    true=~0 false=~~0 Хотя особенно и не настаиваю.
    А вот сравнение действительных чисел на 0 как то не правильно учитывая относительность и погрешность.
    Хотя все по ситуации.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[4]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 14:02
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Сергей Губанов пишет:


    >> Там где есть процессы/потоки — там нет активных объектов, и наоборот.


    C>Ваш "активный объект" — это и есть поток.


    Активный объект не поток, он концептуальный аналог максимально облегченного процесса.

    Процессы/потоки — это абстракции операционной системы типа Windows/Linux и т.д., без операционной системы никаких процессов/потоков не существует.

    Активные объекты — это некие первосущности существующие без операционных систем, операционные системы работают поверх них. Теоретически, можно выгрузить всю операционку, а кое какие объекты оставить в покое, потом загрузить другую операционку, а то и две сразу... Скажете фантастика?
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 09.02.05 14:07
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>...С таким массивом, естественно, надо будет работать так:

    СГ>
    СГ>FOR i := 0 TO LEN(mat) DO
    СГ>  FOR j := 0 TO LEN(mat[i]) DO
    СГ>    mat[i, j] := 0.0;
    СГ>  END
    СГ>END
    СГ>



    Забыл отнять -1:

    FOR i := 0 TO LEN(mat)-1 DO
      FOR j := 0 TO LEN(mat[i])-1 DO
        mat[i, j] := 0.0;
      END
    END
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 09.02.05 14:11
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>У Вас путаница в голове. Сборщик мусора работает с памятью, а к модулям он никакого отношения не имеет. К модулям имеет отношение динамический загрузчик. Чтобы выгрузить загруженный ранее модуль нужно явно дать определенную команду. Например, в BlackBox модуль выгружается вызовом процедуры Kernel.UnloadMod(mod: Module); Впрочем, если этот модуль в данный момент используется другими модулями, то эта процедура ничего не делает.


    Вот именно — ничего не делает. Я не о сборщике мусора спрашивал, а о том, как модуль обновить. Так что насчет путаницы в голове Вы, думаю, погорячились.
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 09.02.05 14:12
    Оценка:
    Сергей Губанов пишет:

    > C>Сергей Губанов пишет:

    >>> Там где есть процессы/потоки — там нет активных объектов, и наоборот.
    > C>Ваш "активный объект" — это и есть поток.
    > Активный объект не поток, он *концептуальный аналог* максимально
    > облегченного процесса.

    Поток характеризуется:
    1. Параллельным выполнением.
    2. Отсутствием неявного разделения данных.
    И НИГДЕ здесь нет слов про Linux, Windows и ОС вообще...

    "Активные объекты" удволетворяют обоим критериям.

    Например, в MFC можно сделать "активный объекты", наследуя их от
    CAppThread

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[3]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 09.02.05 14:29
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Все гораздо проще.


    (не проще, а изоморфно)

    СГ>Объекту вполне достаточно по своей воле не прекращать своей собственной активности хоть до бесконечности и он не будет никогда удален.


    СГ>Рантайм система языка Active Oberon гарантирует, что сборщик мусора не будет удалять объект до тех пор пока он активный. После того как объект перестает быть активным, вот тогда сборщик мусора может его удалить если конечно на него нет ссылок. Ну это и понятно. Ведь когда объект активен, то по крайней мере одна ссылка-то на него всегда есть — ведь стоит же он в очереди за процессорным временем (своим time slice). Когда он перестает быть активным, то есть в очереди за процессорным временем он больше не стоит — по его душу придет GC и сделает свое дело.


    Можно так сказать: все подлинно активные объекты зацеплены за очередь планировщика.

    СГ>Вывод — чтобы изничтожить неугодный активный объект достаточно убрать его из очереди за процессорным временем.


    Во-первых, вылететь из очереди планировщика можно тремя способами:
    — из running в waiting
    — из running в suspended
    — из ready в suspended
    Для вытесняющей многозадачности переход running->ready может случиться по внешним причинам (например, по прерыванию).
    Это означает, что какой-то инвариант может быть нарушен. Естественно, после возврата в running инвариант объект восстановит инвариант; кроме того, программист всегда может установить, какие качества системы зависят от подвисания объекта, а какие не зависят и могут безопасно использоваться. Но сборка мусора — знает ли она об этом?

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

    В третьих, алгоритм работы объекта-демона принципиально состоит в бесконечном цикле (точнее, он выходит из цикла, получив сигнал остановки). А значит, он может что-нибудь зацепить...

    Обнаружив факт полного выжирания памяти, сборщик мусора должен выяснить: какие демоны можно перезапустить. Как он это сделает, в условиях единого адресного пространства?
    Перекуём баги на фичи!
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 14:32
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:

    КЕ>На всякий случай поясню свою точку зрения. Вне зависимости от того как работает operator bool(), лучше вообще его не вводить, в C++ "хватает" преобразования к float.


    В принципе, согласен.
    Но, в данном частном случае, его введение, видимо, оправдано.
    Пример я недавно приводил (в посте Кодту):
    #include <stdio.h>
    
    int main()
    {
        float x;
        int *p = (int *) &x;
    
        *p = 0x007fffff;
        printf("%.15f %c= zero\n", x, (x) ? '!' : '=');
        return 0;
    }

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[4]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 16:11
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    СГ>>Вывод — чтобы изничтожить неугодный активный объект достаточно убрать его из очереди за процессорным временем.

    К>Во-первых, вылететь из очереди планировщика можно тремя способами:
    К>- из running в waiting
    К>- из running в suspended
    К>- из ready в suspended

    ИМХО, это зависит от ОС.
    Может быть три способа, а может быть тридцать три.

    К>Для вытесняющей многозадачности переход running->ready может случиться по внешним причинам (например, по прерыванию).

    К>Это означает, что какой-то инвариант может быть нарушен. Естественно, после возврата в running инвариант объект восстановит инвариант; кроме того, программист всегда может установить, какие качества системы зависят от подвисания объекта, а какие не зависят и могут безопасно использоваться. Но сборка мусора — знает ли она об этом?

    Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)
    Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.

    К>Во-вторых, вне зависимости от этого, сохраняется вопрос о легальности уничтожения ждущего объекта.


    Здесь нет ничего специфичного для ОС Оберон.
    На что, кстати, уже обращалось внимание.

    К>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.


    Откуда?
    Вопрос неясен.

    К>В третьих, алгоритм работы объекта-демона принципиально состоит в бесконечном цикле (точнее, он выходит из цикла, получив сигнал остановки). А значит, он может что-нибудь зацепить...


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

    К>Обнаружив факт полного выжирания памяти, сборщик мусора должен выяснить: какие демоны можно перезапустить. Как он это сделает, в условиях единого адресного пространства?


    А как он это сделает в условиях нескольких адресных пространств?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 09.02.05 16:46
    Оценка:
    AVC пишет:

    > То, что в Си++ это можно делать не на уровне языка — достоинство.

    > Но не новое, и свойственное многим языкам.
    > Разница только в том, что Си++ перегружает оператор индексации. Т.е.
    > можно использовать квадратные скобки, а в других языках используются
    > круглые. Мне кажется, что это не принципиально.
    > А вот то, что в Си++ это *не* сделано на уровне языка — явный недостаток.

    А зачем это на уровне языка? И почему на уровне языка должны быть именно
    прямоугольные массивы, а не разреженные матрицы в виде мультисписков?
    Чем прямоугольники лучше?

    > К>А если какое-то представление оказалось зашито в язык, то оно ставит

    > остальные в неравные условия перед разработчиком алгоритмов.
    > Просто доведите это свое утверждение до логического конца.
    > Вы придете к языку ассемблера.

    Ну так C и создавался как низкоуровневый язык, ближайшая замена
    ассемблеру. На а С++ унаследовал (частично) дух С.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 09.02.05 17:15
    Оценка:
    AVC пишет:

    >>> А вот то, что в Си++ это *не* сделано на уровне языка — явный

    > недостаток.
    > C>А зачем это на уровне языка? И почему на уровне языка должны быть
    > именно
    > C>прямоугольные массивы, а не разреженные матрицы в виде мультисписков?
    > C>Чем прямоугольники лучше?
    > Просто есть базовые конструкции. То, из чего конструируются все остальные.

    Я, например, не считаю прямоугольный многомерный массив базовой
    конструкцией. Одномерный массив — это действительно база (дальше уже
    некуда).

    > А есть сложные динамические структуры, которые из них строятся.

    > Как правило, они используются для представления АТД, создаваемых
    > программистом для решения конкретной задачи.
    > А еще есть некоторый логический порядок абстракций.
    > Например, сначала целые числа, затем вещественные, затем — комплексные.

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

    > Об этом я и говорю.

    > А то некоторые утверждают, что Си++ — сильно типизированный язык.

    Он сильно типизирован, просто предусмотрены варианты обхода типизации

    > Тогда как отовсюду "торчит" Си.

    > Только Си — простой, маленький и честный язык.
    > А Си++ пытается усидеть на всех стульях сразу.

    И у него это получается. Не идеально, конечно, но получается.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[48]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 09.02.05 17:43
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Я, например, не считаю прямоугольный многомерный массив базовой

    C>конструкцией. Одномерный массив — это действительно база (дальше уже
    C>некуда).

    И я так думаю.
    Одномерный (гибкий) массив — базовая конструкция.
    А теперь я хочу получить массив массивов.
    Т.к. массив — базовая конструкция, то язык должен это позволять.
    А Си++ — не позволяет.

    >> Об этом я и говорю.

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

    Если есть обход, то это не сильная типизация.
    Но это мы уже обсуждали.

    >> Тогда как отовсюду "торчит" Си.

    >> Только Си — простой, маленький и честный язык.
    >> А Си++ пытается усидеть на всех стульях сразу.
    C>И у него это получается. Не идеально, конечно, но получается.

    Пока.
    А когда выйдет новый стандарт?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Astaroth Россия  
    Дата: 09.02.05 18:05
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Ну в 50Кб кода я тоже не верю А вот дискета-другая — вполне реально.


    Ну, floppy-based дистрибутивов того же пингвина — как грязи.
    ... << RSDN@Home 1.1.4 beta 3 rev. 279>>
    http://livejournal.com/users/breqwas
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: Astaroth Россия  
    Дата: 09.02.05 18:05
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>>>В принципе, Си++ — язык для детской песочницы.

    WH>>Такое себе даже фанаты C# не позволяют.
    AVC>Зато позволяют себе правительства Канады и Великобритании.

    Тогда прошу предъявить мне либо ссылку, где правительства Канады и Великобритании заявляют, что "Си++ — язык для детской песочницы", либо доказательства того, что AVC является правительством Канади и Великобритании
    ... << RSDN@Home 1.1.4 beta 3 rev. 279>>
    http://livejournal.com/users/breqwas
    Re[49]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 09.02.05 18:30
    Оценка:
    AVC пишет:

    > C>Я, например, не считаю прямоугольный многомерный массив базовой

    > C>конструкцией. Одномерный массив — это действительно база (дальше уже
    > C>некуда).
    > И я так думаю.
    > Одномерный (гибкий) массив — базовая конструкция.
    > А теперь я хочу получить массив массивов.

    А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
    разных условий лучше подходят разные варианты.

    > Т.к. массив — базовая конструкция, то язык должен это позволять.

    > А Си++ — не позволяет.

    boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

    А вот сделать разреженную матрицу на Обероне красиво не получится.
    Вместо оператора индекса будет всякие функции типа GetElement().

    >>> Об этом я и говорю.

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

    Она сильная, но отключаемая

    >>> Только Си — простой, маленький и честный язык.

    >>> А Си++ пытается усидеть на всех стульях сразу.
    > C>И у него это получается. Не идеально, конечно, но получается.
    > *Пока*.
    > А когда выйдет новый стандарт?

    Недавно, кажется вышел. Добавили стандартный ABI.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[35]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 10.02.05 06:40
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.

    AVC>С ним можно не соглашаться, но почитать его опусы стоит (imho).
    AVC>Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
    AVC>Лично мне наиболее интересной кажется статейка
    AVC>http://www.amadeus-3.com/main_files/FlawsOfCPP.php
    AVC>но можно почитать и
    AVC>http://www.amadeus-3.com/main_files/oberon2vsCPP.php

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

    Без всякой иронии — как измерялась производительность этого парня? Вопрос об измерении производительности программиста поднимается не реже, чем Oberon vs. C++, поэтому интересно знать, какие критерии использовались в данном случае.

    AVC>Так что моя "критика" — совсем не вопли злобного "аутсайдера". :)

    AVC>Но именно поэтому я не могу не чувствовать внутреннего напряжения, нарастающего в языке.
    AVC>Стали заметны нестыковки, ограничения (explicit), ограничения ограничений (mutuable), "подпружные арки и контрфорсы". :)

    А может, все недостатки C++ происходят оттого, что проектировался он не в академической организации, а в коммерческой структуре? Подход к разработке в коммерческих и академических организациях сильно различается. В исследовательской лаборатории можно одним махом выбросить старую платформу и перейти на новую. Вирт не раз так делал. Например, он призывал всех отказаться от Паскаля в пользу Модулы-2. Но в жизни, в жестких условиях временных, бюджетных и прочих ограничений, подобное, как правило, невозможно. Отсюда требование — сохранить совместимость со старым работающим софтом. А дальше так: ввели в язык, например, перегрузку, и появилось ключевое слово overload. И сохранялось оно в C++ годы. Потому что кто-то где-то его использовал. Так что проблема избавления от анахронизмов — гораздо более сложная, чем изобретение новых возможностей.

    AVC>Главное: инструмент перестал умещаться в руке.


    Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 10.02.05 07:34
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:
    СГ>В Обероне, в отличие от Java и от C#, массивы есть всякие.
    Неверно. Сам .Net поддерживает N-мерные массивы, в том числе и не 0-based. Т.е. можно использовать массив типа int[1..5, -3..8]. В C# на уровне синтаксиса поддерживаются только 0-based размерности.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[5]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 10.02.05 08:04
    Оценка:
    Здравствуйте, AVC, Вы писали:

    СГ>>>Вывод — чтобы изничтожить неугодный активный объект достаточно убрать его из очереди за процессорным временем.

    К>>Во-первых, вылететь из очереди планировщика можно тремя способами:
    К>>- из running в waiting
    К>>- из running в suspended
    К>>- из ready в suspended

    AVC>ИМХО, это зависит от ОС.

    AVC>Может быть три способа, а может быть тридцать три.

    Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

    К>>Для вытесняющей многозадачности переход running->ready может случиться по внешним причинам (например, по прерыванию).

    К>>Это означает, что какой-то инвариант может быть нарушен. Естественно, после возврата в running инвариант объект восстановит инвариант; кроме того, программист всегда может установить, какие качества системы зависят от подвисания объекта, а какие не зависят и могут безопасно использоваться. Но сборка мусора — знает ли она об этом?

    AVC>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)

    AVC>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.

    Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

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

    К>>Во-вторых, вне зависимости от этого, сохраняется вопрос о легальности уничтожения ждущего объекта.


    AVC>Здесь нет ничего специфичного для ОС Оберон.

    AVC>На что, кстати, уже обращалось внимание.

    А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

    К>>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.


    AVC>Откуда?

    AVC>Вопрос неясен.

    Откуда: из очереди к ресурсу.

    К>>В третьих, алгоритм работы объекта-демона принципиально состоит в бесконечном цикле (точнее, он выходит из цикла, получив сигнал остановки). А значит, он может что-нибудь зацепить...


    AVC>Если активный объект цепляет что-то за свой стек (никак не привыкну к этому выражению ), то при его удалении память может быть освобождена.


    Так ведь удаления-то не произойдёт! Объект всё время активен (молотит цикл ожидания)...

    К>>Обнаружив факт полного выжирания памяти, сборщик мусора должен выяснить: какие демоны можно перезапустить. Как он это сделает, в условиях единого адресного пространства?


    AVC>А как он это сделает в условиях нескольких адресных пространств?


    Процесс, выжравший свою квоту (или все ресурсы, если квота бесконечна), получит звоночек. Если звоночек не обработан, то процесс уничтожается, освобождая ресурсы. Остальные процессы при этом не страдают.
    Перекуём баги на фичи!
    Re[51]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 10.02.05 08:12
    Оценка:
    Здравствуйте, AVC, Вы писали:

    >>> Одномерный (гибкий) массив — базовая конструкция.

    >>> А теперь я хочу получить массив массивов.
    C>>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем для
    C>>разных условий лучше подходят разные варианты.

    AVC>Я не против других вариантов.

    AVC>Но Вы все же лукавите. Я же ясно написал — массив массивов, причем мы договорились называть массивом базовую конструкцию языка. Так что вариант, конечно, в данном случае только один.

    >>> Т.к. массив — базовая конструкция, то язык должен это позволять.

    >>> А Си++ — не позволяет.
    C>>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...

    AVC>Ах, увы... впрочем, что это я?

    AVC>А что, массива — просто мас-си-ва — сегодня в продаже нет?

    Ты сам лукавишь. Есть массив массивов в продаже. Есть!!! С учётом того, что указатель на одиночный элемент и указатель на массив в С++ неразличимы, то
    Element square[X][Y];
    
    Element* jagged[X];
    jagged[0] = new Element[Y1];
    jagged[1] = new Element[Y2]; ...
    
    square[1][2] = Element(123);
    jagged[1][2] = Element(456);

    Для тех, кому не нравится смешивать одиночные элементы и массивы — см. boost::array и т.п.
    Для тех, кому хочется динамики — см. std::vector.
    Перекуём баги на фичи!
    Re[52]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 08:48
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К> Есть массив массивов в продаже. Есть!!! С учётом того, что указатель на одиночный элемент и указатель на массив в С++ неразличимы, то

    К>
    К>Element square[X][Y];
    
    К>Element* jagged[X];
    К>jagged[0] = new Element[Y1];
    К>jagged[1] = new Element[Y2]; ...
    
    К>square[1][2] = Element(123);
    К>jagged[1][2] = Element(456);
    К>

    К>Для тех, кому не нравится смешивать одиночные элементы и массивы — см. boost::array и т.п.
    К>Для тех, кому хочется динамики — см. std::vector.

    Да как же? Не вижу я чего-то массива массивов.

    Ваш square[X][Y] — это двумерный массив.
    Ваш *jagged[X] — это массив указателей.

    В то время как массив массивов вот какой: ARRAY OF ARRAY OF Element.

    "ARRAY OF", и "ARRAY N OF" — это базовые типы. Комбинируя их в сочетании с другим базовым типом "POINTER TO" можем получить очень много разных комбинаций (почувствуйте разницу):
    TYPE
      A1 = ARRAY dim0, dim1 OF Element;
      A2 = ARRAY OF ARRAY OF Element;
      A3 = POINTER TO ARRAY dim0, dim1 OF Element;
      A4 = POINTER TO ARRAY OF ARRAY OF Element;
      A5 = ARRAY OF POINTER TO ARRAY OF Element;
      A6 = ARRAY dim0 OF POINTER TO ARRAY OF Element;
      A7 = POINTER TO ARRAY OF POINTER TO ARRAY OF Element;
      A8 = POINTER TO ARRAY OF POINTER TO ARRAY dim1 OF Element;
      A9 = POINTER TO ARRAY dim0 OF POINTER TO ARRAY dim1 OF Element;
      A10 = POINTER TO ARRAY dim0 OF POINTER TO ARRAY OF Element;
      ...
      и так далее - разных вариантов превеликое множество....

    Так что, извините, но самого обычного массива массивов в Си/Си++ нет.
    MODULE  Test;
    
        PROCEDURE P1 (VAR array: ARRAY OF REAL);
            VAR i: INTEGER;
        BEGIN
            FOR i := 0 TO LEN(array)-1 DO
                array[i] := 0.0
            END
        END P1;
    
        PROCEDURE Calculate (VAR mat: ARRAY OF ARRAY OF REAL);
            VAR dim0, dim1, i, j: INTEGER;
        BEGIN
            dim0 := LEN(mat, 0);
            dim1 := LEN(mat, 1);
            FOR i := 0 TO dim0-1 DO
                FOR j := 0 TO dim1-1 DO
                    mat[i, j] := 0.0;
                END
            END
        END Calculate;
    
        PROCEDURE Test (  );
            VAR a: ARRAY 192, 256 OF REAL;
            b: POINTER TO ARRAY 4096, 1024 OF REAL;
            c: POINTER TO ARRAY OF ARRAY OF REAL;
        BEGIN
            Calculate(a);
            P1(a[2]);
            
            NEW(b);
            Calculate(b);
            P1(b[3]);
            
            NEW(c, 8128, 512);
            Calculate(c);
            P1(c[4]);
            
        END Test;
        
    
    END  Test.
    Re[6]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 09:39
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).


    В Aos они другие и их больше:

    http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&amp;nr=14755

    5.9.1 Process States

    A process can be in one of several states, and with every state (except
    Terminated) is associated a data structure which stores descriptors of
    processes in that state. It follows that a process can only be in one of
    these data structures at any time — when it switches state it is also
    moved from one data structure to another. The states and all possible
    transitions between them are shown in figure 5.6 and described below:

    Ready This is the initial state of a process. It is ready to run and
    waiting for a processor to be assigned to it, at which time it will
    move to the Running state.

    Running A process is in this state when it is running on one of the
    available processors. It leaves this state when it terminates, is
    preempted, or starts waiting for a lock, condition or interrupt.

    AwaitingLock A process is in this state when it is waiting to acquire
    an object lock that is held by another process. When it eventually
    acquires the lock, it moves back to the Ready state.

    AwaitingCondition A process is in this state when it is waiting for
    a condition to be made true by some other process. When the
    condition is eventually found to be true by the runtime system,
    the process moves back to the Ready state.

    AwaitingInterrupt A process (typically a device driver) is in this
    state when it is waiting for a specific interrupt to occur. This
    is similar to the previous state, except that the process will be
    enabled to run by an interrupt, and not the actions of another
    process (cf. 4.3.3). When it is enabled, it moves back to the Ready
    state.

    Terminated This is the final state, which is entered when a process terminates.
    Terminated process descriptors are not in any programdefined
    data structure, but remain in the heap until they are
    cleaned up by the garbage collector.

    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 10.02.05 09:58
    Оценка:
    Hello, Сергей!
    You wrote on Thu, 10 Feb 2005 09:22:19 GMT:

    СГ> Как Вы в MFC реализуете AWAIT? А никак, разьве только бесконечным

    СГ> циклом который будет есть процессорное время постоянно проверяя условие
    СГ> истинности!!! Кстати, не забудьте, что EXCLUSIVE — это метка блока
    СГ> исполняющегося целиком, как одна элементарная (атомарная) инструкция. И
    СГ> внутри этой атомарной элементарной инструкции Вы должны будете
    СГ> запустить бесконечный цикл проверки условия AWAT(condition)...

    Сказки только не надо рассказывать — это делается элементарно без всяких
    оберонов. EnterCriticalSection/LeaveCriticalSection (или, по вкусу —
    boost::mutex/boost::mutex::scoped_lock) на замену EXCLUSIVE подойдут вполне.
    А AWAIT может быть реализован хоть на бесконечном цикле со Sleep(0) внутри,
    хоть на WaitForSingleObject, хоть на любом другом удобном для конкретного
    случая примитиве.

    СГ>

    СГ> Подсказка.
    СГ> В рантайм системе Aos инструкция AWAIT просто ставит активность
    СГ> (активный объект) в очередь ожидания выполнения условия, так что лишнее
    СГ> процессорное время не расходуется. Активных объектов одновременно может
    СГ> быть десятки тысяч! Представьте что будет (в случае MFC), кода 50'000
    СГ> потоков будут каждый в своем бесконечном цикле AWAIT дожидаться
    СГ> чего-нибудь. Вроде ничего не происходит, все просто чего-то ждут, а
    СГ> процессор загружен на 100%.

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

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 10:26
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Ещё раз для тех, кто в Обероне: указатель на массив и указатель на одиночный элемент в С/С++ неразличимы.


    Для тех, кто в Си++. (Хотя пока и вынужденно кратко.)
    1) Помедитируйте над Вашим утверждением в свете планов Страуструпа о введении GC в Си++.
    "Шелковистые волосы" на голове не шевелятся?
    2) Слава Богу, оно не на 100% соответствует действительности.
    Сравним две конструкции:
    delete p;

    и
    delete [] p;

    Как всегда — "повешено" на программиста.
    3) Все это вообще не имеет отношения к делу.
    ARRAY OF ARRAY OF REAL (например) — это не массив указателей, а именно массив массивов.
    Т.е., наверное, то, что Privalov называет "одним массивом".
    Т.к. в Си++ нельзя написать
    void foo(float a[][]);


    то массива массивов (по крайней мере, в этом смысле) в Си++ нет.

    СГ>>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.

    К>Беспочвенный шовинизм.

    С чьей стороны?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 10:26
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    СГ>>Так что, извините, но самого обычного массива массивов в Си/Си++ нет.


    К>Беспочвенный шовинизм.


    Ничего подобного.

    Oberon
    Вариант первый:
    TYPE
      ArrayOfArray = ARRAY OF ARRAY OF INTEGER;

    Вариант второй:
    TYPE
      ArrayOfInteger = ARRAY OF INTEGER;
      ArrayOfArray = ARRAY OF ArrayOfInteger;






    Теперь посмотрим как это будет в Си/Си++.
    Может быть так:
        typedef int ArrayOfArray[][]; // Ошибка компиляции

    опаньки, не компилируется. Черт побери, а может быть вот так будет правильно:
        typedef int Array[];
        typedef Array ArrayOfArray[]; // Ошибка компиляции

    опаньки, опять не компилируется!

    Visual C++ Concepts: Building a C/C++ Program
    Compiler Error C2087'identifier' : missing subscript

    The definition of an array with multiple subscripts is missing a subscript value for a dimension higher than one. The following sample generates C2087:

    // C2087.cpp
    int main()
    {
    char a[10][]; // C2087
    char b[4][5]; // OK
    }

    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 10:48
    Оценка:
    Здравствуйте, Sergey, Вы писали:

    S>Сказки только не надо рассказывать — это делается элементарно без всяких

    S>оберонов. EnterCriticalSection/LeaveCriticalSection (или, по вкусу —
    S>boost::mutex/boost::mutex::scoped_lock) на замену EXCLUSIVE подойдут вполне.
    S>А AWAIT может быть реализован хоть на бесконечном цикле со Sleep(0) внутри,
    S>хоть на WaitForSingleObject, хоть на любом другом удобном для конкретного
    S>случая примитиве.


    Естественно, что в не ОО системах типа UNIX/Windows процессы/потоки которых есть надстройка над ядром ОСи, для синхронизации используются объекты самой (нижележащей) ОСи.

    А вот активные объекты существуют без операционной системы прямо на голом железе (точнее поверх рантайм системы языка программирования), там наоборот — операционная система состоит из них находится выше.

    Следовательно ничем принадлежащим ОСи активные объекты для своей синхронизации пользоваться не могут.

    Про элементарность:
    Для описания синхронизации активных объектов используется всего два слова EXCLUSIVE и AWAIT — вот уж поистине элементарно, а Вы что назвали элементарным — сонмище всяких: EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep, WaitForSingleObject и т.д.


    Примеры реализации типичных "параллельных паттернов" посредством EXCLUSIVE и AWAIT:

    http://bluebottle.ethz.ch/languagereport/node8.html
    Readers and Writers
    Signals
    Re-entrant Locks
    Binary and Generic Semaphores
    Barrier
    Bounded Buffer

    http://bluebottle.ethz.ch/languagereport/node9.html
    Dining Philosophers
    Sieve of Eratosthenes

    http://bluebottle.ethz.ch/languagereport/index.html
    Active Oberon Language Report
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 10.02.05 11:40
    Оценка:
    Hello, Сергей!
    You wrote on Thu, 10 Feb 2005 10:48:41 GMT:

    СГ> А вот активные объекты существуют без операционной системы прямо на

    СГ> голом железе (точнее поверх рантайм системы языка программирования),
    СГ> там наоборот — операционная система состоит из них находится выше.

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

    СГ> Следовательно ничем принадлежащим ОСи активные объекты для своей

    СГ> синхронизации пользоваться не могут.
    Да пусть не пользуются. В MFC-то примитивами синхронизации никто
    пользоваться не запрещает.

    СГ> Про элементарность:

    СГ> Для описания синхронизации активных объектов используется всего два
    СГ> слова EXCLUSIVE и AWAIT — вот уж поистине элементарно, а
    СГ> Вы что назвали элементарным — сонмище всяких:
    СГ> EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
    СГ> WaitForSingleObject и т.д.

    Сонмище — это потому что выбор есть
    На самом деле твоя комбинация из EXCLUSIVE и AWAIT на С++ может выглядеть,
    например, так:
    
    lock lk(monitor);
    
    while (buffered == 0)
    
        buffer_not_empty.wait(lk);



    ну а весь bounded buffer на C++ может выглядеть, например, так:

    class bounded_buffer : private boost::noncopyable
    {
    public:
        typedef boost::mutex::scoped_lock lock;
    
        bounded_buffer(int n) : begin(0), end(0), buffered(0), circular_buf(n) 
    { }
    
        void send (int m) {
            lock lk(monitor);
            while (buffered == circular_buf.size())
                buffer_not_full.wait(lk);
            circular_buf[end] = m;
            end = (end+1) % circular_buf.size();
            ++buffered;
            buffer_not_empty.notify_one();
        }
        int receive() {
            lock lk(monitor);
            while (buffered == 0)
                buffer_not_empty.wait(lk);
            int i = circular_buf[begin];
            begin = (begin+1) % circular_buf.size();
            --buffered;
            buffer_not_full.notify_one();
            return i;
        }
    
    private:
        int begin, end, buffered;
        std::vector<int> circular_buf;
        boost::condition buffer_not_full, buffer_not_empty;
        boost::mutex monitor;
    };


    СГ> Примеры реализации типичных "параллельных паттернов" посредством

    СГ> EXCLUSIVE и AWAIT:

    Я вашей мовы паскальской не разумею

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
    Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[36]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 12:20
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    AVC>>В данном случае источник информации — Стефан Метцелер, субъект весьма интересный.

    AVC>>С ним можно не соглашаться, но почитать его опусы стоит (imho).
    AVC>>Хотя бы потому, что его программистская производительность на порядок превосходит уровень "продвинутого" С++нутого программиста.
    AVC>>Лично мне наиболее интересной кажется статейка
    AVC>>http://www.amadeus-3.com/main_files/FlawsOfCPP.php
    AVC>>но можно почитать и
    AVC>>http://www.amadeus-3.com/main_files/oberon2vsCPP.php

    P>Статьи как статьи. С ними можно соглашаться, можно спорить.


    Именно это я и сказал.

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


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

    P>Без всякой иронии — как измерялась производительность этого парня? Вопрос об измерении производительности программиста поднимается не реже, чем Oberon vs. C++, поэтому интересно знать, какие критерии использовались в данном случае.


    Ну, например:

    Unless you know other programmers who manage to write a complete OO Framework such as Amadeus-3 in their "spare time", while developing about 20 serious applications for major, multi-national companies (Du Pont de Nemours, Royal Bank of Canada, HP etc.) over a period of 8 years, this should convince you that Oberon-2 programming is indeed as efficient as claimed on this site.


    P>А может, все недостатки C++ происходят оттого, что проектировался он не в академической организации, а в коммерческой структуре? Подход к разработке в коммерческих и академических организациях сильно различается. В исследовательской лаборатории можно одним махом выбросить старую платформу и перейти на новую. Вирт не раз так делал. Например, он призывал всех отказаться от Паскаля в пользу Модулы-2. Но в жизни, в жестких условиях временных, бюджетных и прочих ограничений, подобное, как правило, невозможно. Отсюда требование — сохранить совместимость со старым работающим софтом. А дальше так: ввели в язык, например, перегрузку, и появилось ключевое слово overload. И сохранялось оно в C++ годы. Потому что кто-то где-то его использовал. Так что проблема избавления от анахронизмов — гораздо более сложная, чем изобретение новых возможностей.


    AVC>>Главное: инструмент перестал умещаться в руке.

    P>Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.

    У меня — уже нет.
    Отсюда и недовольство.
    А ведь был неплохой инструмент.

    Что же касается "академизма" Вирта и "давления индустрии" на Страуструпа, то, ИМХО, это все — байки.
    Я знаю несколько программ — компиляторов, операционных систем, встроенных систем и т.д., написанных лично Виртом.
    И не знаю ни одного серьезного приложения, написанного Страуструпом.
    Также не думаю, что на Страуструпа сильно давили в Bell Laboratories.
    Ведь там, кроме Си, было создано множество языков.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[51]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 12:37
    Оценка:
    AVC пишет:

    > C>А _КАКОЙ_ массив массивов? Их несколько вариантов может быть, причем

    > для
    > C>разных условий лучше подходят разные варианты.
    > Я не против других вариантов.
    > Но Вы все же лукавите. Я же ясно написал — массив *массивов*, причем
    > мы договорились называть массивом *базовую конструкцию языка*. Так что
    > вариант, конечно, *в данном случае* только один.

    Да?

    std::vector<std::vector<something> > - вот и массив массивов.

    или так:
    int arr[xdim*ydim];

    и даже вот так:
    template<class T> struct MatrixEntry
    {
        MatrixEntry<T> *nextInRow, *prevInRow, *nextInColumn, *prevInColumn;
        T val;
    };


    >>> Т.к. массив — базовая конструкция, то язык должен это позволять.

    >>> А Си++ — не позволяет.
    > C>boost::multi_array, и ваши волосы будут мягкими и шелковистыми...
    > Ах, увы... впрочем, что это я?
    > А что, массива — *просто мас-си-ва* — сегодня в продаже нет?

    А зачем он нужен "просто массив"?

    > C>А вот сделать разреженную матрицу на Обероне красиво не получится.

    > C>Вместо оператора индекса будет всякие функции типа GetElement().
    > Да, блин, что-то некрасиво получается.
    > GetElement(), уродство какое-то...

    Да, уродство.

    >>> Если есть обход, то это не сильная типизация.

    > C>Она сильная, но отключаемая
    > Что-то мне это напоминает ежика:
    > Сильный-то я сильный. Но легкий.

    Примерно так.

    >>> А когда выйдет новый стандарт?

    > C>Недавно, кажется вышел. Добавили стандартный ABI.
    > Тут я "зарапортовался". Получилась двусмысленность. Как будто я с
    > нетерпением ожидаю еще одного стандарта Си++, от которого мои
    > "шелковистые волосы" прорастут уж в совсем неожиданных местах.
    > Я хотел сказать, что *пока* еще Си++ удается усидеть на нескольких
    > стульях.

    В новом стандарте почти нет измений, просто стандартизовали ABI.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[55]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 13:02
    Оценка:
    AVC пишет:

    > К>Ещё раз для тех, кто в Обероне: указатель на массив и указатель на

    > одиночный элемент в С/С++ неразличимы.
    > Для тех, кто в Си++. (Хотя пока и вынужденно кратко.)
    > 1) Помедитируйте над Вашим утверждением в свете планов Страуструпа о
    > введении GC в Си++.
    > "Шелковистые волосы" на голове не шевелятся?

    Дык, уже. MC++, аднака.

    > Как всегда — "повешено" на программиста.


    Поэтому и надо boost::array использовать

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 13:15
    Оценка:
    Сергей Губанов пишет:

    > Про элементарность:

    > Для описания синхронизации активных объектов используется всего два
    > слова *EXCLUSIVE* и *AWAIT* — вот уж поистине элементарно, а Вы что
    > назвали элементарным — сонмище всяких:
    > EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
    > WaitForSingleObject и т.д.

    И вот так в Обероне всегда... То что придумал Вирт — единственный и
    правильный путь к счастью.

    Мьютексы и критические секции отличаются, например, скоростью работы и
    механизмом блокировки. А WFSO — это просто готовая реализация монитора.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 13:32
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Сергей Губанов пишет:

    >> Про элементарность:
    >> Для описания синхронизации активных объектов используется всего два
    >> слова *EXCLUSIVE* и *AWAIT* — вот уж поистине элементарно, а Вы что
    >> назвали элементарным — сонмище всяких:
    >> EnterCriticalSection/LeaveCriticalSection, Mutex, Sleep,
    >> WaitForSingleObject и т.д.
    C>И вот так в Обероне всегда... То что придумал Вирт — единственный и
    C>правильный путь к счастью.
    C>Мьютексы и критические секции отличаются, например, скоростью работы и
    C>механизмом блокировки. А WFSO — это просто готовая реализация монитора.

    Все это не по делу.
    AWAIT придумал не Вирт, а Бринч Хансен.
    Это высокоуровневая и очень простая в использовании конструкция, существенно проще для программиста, чем сигналы, мониторы, критические секции.
    Поэтому она часто используется в литературе, посвященной многопоточности. (Например, в книге Эндрюса.)
    Что может быть проще в использовании, чем, например, упомянутое Сергеем
    AWAIT(n # 0);
    ?
    Но до последнего времени не было эффективной реализации AWAIT.
    А Питер Мюллер, похоже, сумел сформулировать условия, при которых AWAIT может быть реализован эффективно. По крайней мере, это утверждается в описании Активного Оберона:

    The AWAIT statement was proposed and investigated by Brinch Hansen [3]
    who showed its conceptual simplicity and elegance, but also thought it would
    be impossible to implement it efficiently. We repropose it in Active Oberon,
    with the conviction that it is a real improvement compared with signals and
    semaphores, because of the unification and clarity it brings; it becomes particularly
    obvious in an object-oriented programming style, where signals and
    semaphores are completely inappropriate because of their unstructured use, as
    they can be inserted arbitrarily in a program. Pieter Muller’s thesis [21] proves,
    that with the appropriate restrictions, AWAIT can be implemented efficiently.
    The language Ada 95 [14] has also a construct called barriers, which is se-mantically
    very similar to Active Oberon’s AWAIT, although with a coarser
    procedure-width granularity.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[52]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 13:53
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Но Вы все же лукавите. Я же ясно написал — массив *массивов*, причем

    >> мы договорились называть массивом *базовую конструкцию языка*. Так что
    >> вариант, конечно, *в данном случае* только один.
    C>Да?
    C>
    C>std::vector<std::vector<something> > - вот и массив массивов.
    C>

    C>или так:
    C>
    C>int arr[xdim*ydim];
    C>

    C>и даже вот так:
    C>
    C>template<class T> struct MatrixEntry
    C>{
    C>    MatrixEntry<T> *nextInRow, *prevInRow, *nextInColumn, *prevInColumn;
    C>    T val;
    C>};
    C>


    А просто
    void foo(float a[][]);
    нельзя?
    Или это тоже... того... некрасиво?

    C>А зачем он нужен "просто массив"?


    Т.е. я еще должен Вам объяснять, как используются массивы?
    Увольте.
    Лучше прочтите на досуге какой-нибудь учебник программирования для начинающих.

    >> C>А вот сделать разреженную матрицу на Обероне красиво не получится.

    >> C>Вместо оператора индекса будет всякие функции типа GetElement().
    >> Да, блин, что-то некрасиво получается.
    >> GetElement(), уродство какое-то...
    C>Да, уродство.

    Особенно если сравнивать с классическими образцами красоты:
    std::vector<std::vector<something> > - вот и массив массивов.

    int arr[xdim*ydim];



    Вообще, наша с Вами дискуссия вырождается в заурядный флейм.
    (Без обид и выяснения, кто прав, а кто виноват. )
    Наверное, нужна творческая пауза.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 13:54
    Оценка:
    AVC пишет:

    > C>И вот так в Обероне всегда... То что придумал Вирт — единственный и

    > C>правильный путь к счастью.
    > C>Мьютексы и критические секции отличаются, например, скоростью работы и
    > C>механизмом блокировки. А WFSO — это просто готовая реализация монитора.
    > Все это не по делу.
    > AWAIT придумал не Вирт, а Бринч Хансен.

    В язык-то добавил ее Вирт.

    > Это высокоуровневая и очень простая в использовании конструкция,

    > существенно проще для программиста, чем сигналы, мониторы, критические
    > секции.

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

    > Поэтому она часто используется в литературе, посвященной

    > многопоточности. (Например, в книге Эндрюса.)
    > Что может быть проще в использовании, чем, например, упомянутое Сергеем
    >
    >AWAIT(n # 0);
    >
    > ?

    WaitForSingleObject в WinAPI, например А если серьезно, то аналог
    AWAIT'а есть в boost'е — называется "condition".

    > The language Ada 95 [14] has also a construct called barriers, which

    > is se-mantically
    > very similar to Active Oberon’s AWAIT, although with a coarser
    > procedure-width granularity.

    Надо на досуге наваять подобное на boost.threads + boost.phoenix.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[53]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 13:58
    Оценка:
    AVC пишет:

    > А просто

    >
    >void foo(float a[][]);
    >
    > нельзя?

    Нет, нельзя. Потому как не "просто" — возможны несколько неравноценных
    вариантов.

    > C>А зачем он нужен "просто массив"?

    > Т.е. я еще должен Вам объяснять, как используются массивы?

    Я имею в виду "просто массив". Чем класс с интерфейсом массива не угодил?

    Кстати, а в Oberon'е можно делать срезы массивов, проекции и т.п.?

    >>> GetElement(), уродство какое-то...

    > C>Да, уродство.
    > Особенно если сравнивать с классическими образцами красоты:
    >
    >std::vector<std::vector<something> > — вот и массив массивов.
    >
    >
    >int arr[xdim*ydim];
    >
    >
    >
    Просто объявления. А доступ будет выглядеть так:
    1) a[0][2]=...;
    2) arr[xdim*y+x]=...;

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[37]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 10.02.05 14:12
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Просто существуют достаточно интересные случаи, когда человек вдруг отходит от языка "мэйнстрима", и начинает пользоваться другим, менее известным и поддерживаемым "промышленностью" языком.

    AVC>При этом добивается значительных результатов (как Метцелер).
    AVC>Конечно, Оберон, не единственный язык, ведущий иногда к таким результатам.
    AVC>Не так давно я наткнулся где-то на статейку Пола Грехема, в которой он поведал, что самое успешные американские коммерческие Web-сайты были созданы на... Лиспе.

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

    AVC>>>Главное: инструмент перестал умещаться в руке.

    P>>Согласен. Есть, впрочем, надежда, что C++ не повторит путь PL/1.

    AVC>У меня — уже нет. :(

    AVC>Отсюда и недовольство.
    AVC>А ведь был неплохой инструмент.

    AVC>Что же касается "академизма" Вирта и "давления индустрии" на Страуструпа, то, ИМХО, это все — байки.

    AVC>Я знаю несколько программ — компиляторов, операционных систем, встроенных систем и т.д., написанных лично Виртом.
    AVC>И не знаю ни одного серьезного приложения, написанного Страуструпом.
    AVC>Также не думаю, что на Страуструпа сильно давили в Bell Laboratories.
    AVC>Ведь там, кроме Си, было создано множество языков.

    Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.

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

    Вирт стремится создать идеальную систему. Здесь можно прочитать о проектах, над которыми он работал. Немногие из них дошли до нас в первозданном виде. (В тот год, когда я стал студентом, обучение программированию стало вестись на базе Фортрана, до этого оно велось на базе алгола. Не думаю, что это наш курс повлиял).

    Страуструп, напротив, практик. Его место работы, можно сказать, КБ или отраслевой НИИ. Основная задача таких организаций — воплощение в жизнь теорий, создаваемых академиками. Где-то на этом форуме уже обсуждалась подобная тема.

    Работа Вирта дала материал для размышления многим, в том числе Страуструпу. Однако, прагматизм последнего (вольный или невольный), несомненно, сыграл свою роль в том, что C++ распространен гораздо шире, чем любой из проектов Вирта.
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 14:14
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    AVC> AWAIT придумал не Вирт, а Бринч Хансен.


    C>В язык-то добавил ее Вирт.


    Опять мимо. Язык Active Oberon создали Юрг Гуткнехт, A. R. Disteli и Patrik Reali. Реализовал систему Aos Питер Мюллер. Эмуляцией Aos-а под Windows занимается, например, Felix Friedrich ETH Win Aos Oberon System.
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 14:18
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных

    C>ОС. Еще рекомендую почитать про O(1) планировщики.

    spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).
    Re[54]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 10.02.05 14:27
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Кстати, а в Oberon'е можно делать срезы массивов, проекции и т.п.?


    Если есть процедура

    PROCEDURE Calculate(VAR vector: ARRAY OF REAL);


    то в нее можно можно передать matrix[n], где matrix — это ARRAY OF ARRAY OF REAL.

    И так далее, если есть процедура на вход которой подается ARRAY OF...ARRAY OF, то в нее можно засунуть "срез"

    {ARRAY OF ... ARRAY OF ARRAY OF ...ARRAY OF ...}{ARRAY OF ...ARRAY OF ...}

    оторвав у этой "пирамиды" макушку, т.е. лишние размерности

    Calculate3D(matrix5D[m, n]);
    3 = 5 — 2

    Calculate4D(matrix7D[m, n, k]);
    4 = 7 — 3
    Re[6]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 14:34
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>>>Во-первых, вылететь из очереди планировщика можно тремя способами:

    К>>>- из running в waiting
    К>>>- из running в suspended
    К>>>- из ready в suspended
    AVC>>ИМХО, это зависит от ОС.
    AVC>>Может быть три способа, а может быть тридцать три.
    К>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

    Так это какими абстракциями пользоваться.
    Я, например, вижу только три состояния:
    1) текущий процесс (running по Вашему);
    2) процесс в очереди исполнения (ready);
    3) ждущий какого-нибудь внешнего события (waiting).
    Конечно, для последнего варианта можно насчитать множество разновидностей.
    Но процесс все равно находится в состоянии ожидания того светлого времени, когда его "разбудит" диспетчер.

    AVC>>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)

    AVC>>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.
    К>Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

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

    К>- сборщик мусора знает о мониторе и честно ждёт (или просто обходит стороной) заблокированные данные; достаточно теперь зависнуть в мониторе (например, на взаимоблокировке или банальном бесконечном цикле) — и привет


    Если мониторы, связанные с управлением памятью, входят в состав ядра ОС, то зависание такого монитора равносильно зависанию ядра.
    А уж если ядро зависло — ничего не попишешь...

    К>- сборщик мусора не знает о мониторах и нагло копается в заблокированных данных, в том числе — на полудохлых


    Только, если существует единственный процесс.

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


    Зачастую вполне приемлимый вариант.
    Пара лишних операций на присваивание указателей все же эффективнее переключения контекста.

    К>>>Во-вторых, вне зависимости от этого, сохраняется вопрос о легальности уничтожения ждущего объекта.

    AVC>>Здесь нет ничего специфичного для ОС Оберон.
    AVC>>На что, кстати, уже обращалось внимание.
    К>А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

    О, искусственный интеллект!

    К>>>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.

    AVC>>Откуда?
    AVC>>Вопрос неясен.
    К>Откуда: из очереди к ресурсу.

    Тогда объект все же зацеплен за очередь к ресурсу.
    В чем дилемма?

    AVC>>А как он это сделает в условиях нескольких адресных пространств?

    К>Процесс, выжравший свою квоту (или все ресурсы, если квота бесконечна), получит звоночек. Если звоночек не обработан, то процесс уничтожается, освобождая ресурсы. Остальные процессы при этом не страдают.

    То же самое, ИМХО, возможно и при едином адресном пространстве.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[52]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 10.02.05 14:41
    Оценка:
    Cyberax,

    >>>> А когда выйдет новый стандарт?


    >> C>Недавно, кажется вышел. Добавили стандартный ABI.


    >> <...>


    > В новом стандарте почти нет измений, просто стандартизовали ABI.


    О каком стандарте идет речь? В 2003 ABI не стандартизировали, просто исправили ошибки 1998-го.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 14:42
    Оценка:
    Сергей Губанов пишет:

    > C>RTFM про spinlock'и и мьютексы, а так же про их реализацию в

    > современных
    > C>ОС. Еще рекомендую почитать про O(1) планировщики.
    > spinlock'и и мьютексы — это объекты операционной системы, а Вы
    > попробуйте обойтись без объектов ОСи — средствами только самого языка
    > программирования.

    Поправка: объектом операционный системы является только мьютекс.
    Критические секции работает исключительно в пользовательском коде
    (смотри документацию на *InterlockedCompareExchange* в MSDN),
    соответственно крит. секции валидны только в пределах текующего процесса.

    > Представьте себе что хотите написать программу которая должна работать

    > на голом железе (точнее — в рантайм системе языка программирования).

    И что? Realtime-программирование не значит отсутствие ОС.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[57]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 16:35
    Оценка:
    Здравствуйте, Павел Кузнецов,

    Главное-то забыл спросить (давно собирался).
    Когда-то (давно) Вы писали о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели.
    Я тогда этот пост "проспал", а теперь немного жалею.
    Можно ли все-таки сделать указатели в Си/Си++ надежными?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 10.02.05 17:06
    Оценка:
    AVC пишет:

    > Главное-то забыл спросить (давно собирался).

    > Когда-то (давно) Вы писали о том, что можно попытаться сделать
    > "надежный" Си, по другому реализовав указатели.
    > Я тогда этот пост "проспал", а теперь немного жалею.
    > Можно ли все-таки сделать указатели в Си/Си++ надежными?

    Да, можно. Есть здесь: http://manju.cs.berkeley.edu/cil/
    Хотя придется отказаться от части функций языка.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 10.02.05 17:09
    Оценка:
    AVC,

    > о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели. Я тогда этот пост "проспал", а теперь немного жалею.


    Гм... Наверное, здесь: http://rsdn.ru/Forum/Message.aspx?mid=888051&amp;only=1
    Автор: Павел Кузнецов
    Дата: 07.11.04


    > Можно ли все-таки сделать указатели в Си/Си++ надежными?


    Можно. Но, очевидно, они перестанут напрямую "ложиться" на аппаратные указатели. Стандарт такой вариант допускает, но практически в этом много проблем. Впрочем, думаю, можно извернуться, предоставив такие проверки, по крайней мере, в отладочном режиме.
    Posted via RSDN NNTP Server 2.0 alpha
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[59]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 17:12
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:

    >> Можно ли все-таки сделать указатели в Си/Си++ надежными?
    C>Да, можно. Есть здесь: http://manju.cs.berkeley.edu/cil/
    C>Хотя придется отказаться от части функций языка.

    Спасибо!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[59]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 10.02.05 17:40
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели. Я тогда этот пост "проспал", а теперь немного жалею.

    ПК>Гм... Наверное, здесь: http://rsdn.ru/Forum/Message.aspx?mid=888051&amp;only=1
    Автор: Павел Кузнецов
    Дата: 07.11.04


    Спасибо, именно этот пост я и пытался вспомнить.
    Примерно такое решение я и предполагал.

    Я помню о своем обещании выдать текст о сравнительной применимости Оберона (по крайней мере, в определенных пределах) по окончании отладки нашего процессора.
    Однако, процесс разработки и отладки у нас затянулся, и только сейчас близится к завершению.
    Иногда сам этот процесс подбрасывал мысли к дискуссии о языках. (Например, неявное приведение bool к float в Си++.)
    В течении этого времени я собирал критику Оберона (и даже провоцировал ее несколько крайними суждениями о Си++ ).
    На самом деле существенной критики не так уж и много.
    Основная критика языка связана с отсутствием аналога шаблонов и дженериков.
    Как я предполагаю, шаблонов в Обероне нет (хотя и есть во многих его расширениях) из-за раздельной компиляции и динамической загрузки.
    Вы тогда упоминали дженерики в C# 2.0.
    Но там требовалась JIT компиляция.
    Как мне кажется, для Оберона вполне приемлем ограниченный вариант дженерика, не требующий дополнительной компиляции вовсе.
    Расширение языка при этом требуется минимальное.
    (Вирт, может быть, придумал бы способ сделать это вовсе не расширяя язык. )

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[58]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 10.02.05 23:00
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Главное-то забыл спросить (давно собирался).

    AVC>Когда-то (давно) Вы писали о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели.
    AVC>Я тогда этот пост "проспал", а теперь немного жалею.
    AVC>Можно ли все-таки сделать указатели в Си/Си++ надежными?

    Например есть т.н. безопасный диалект C Cyclone http://www.research.att.com/projects/cyclone/ , там есть ссылки и на другие подобные проекты. Но лично мне оно не понравилось.
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[10]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 11.02.05 08:14
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>1) Идем на сайт BlueBottle, далее Download Current, далее AosSysSrc.zip, далее AosKernel.mod, смотрим


    Спасибо за такой ответ.
    Кроме Вас еще никто не сподобился скачать BlueBottle и посмотреть на ее исходный код.

    Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.
    Re[59]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 08:39
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:

    AVC>>Можно ли все-таки сделать указатели в Си/Си++ надежными?

    КЕ>Например есть т.н. безопасный диалект C Cyclone http://www.research.att.com/projects/cyclone/ , там есть ссылки и на другие подобные проекты. Но лично мне оно не понравилось.

    Спасибо!
    Скачал, при первой возможности постараюсь вникнуть.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 11.02.05 09:21
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.

    AVC>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
    AVC>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

    А где сейчас те языки, операционки и вертолеты?
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[61]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 09:28
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    AVC>>Но там требовалась JIT компиляция.

    S> Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).

    Спасибо, я и правда почему-то в этот момент забыл, что в .NET все подвергается JIT.
    А хотел я сказать, что Оберон (как язык в целом, а не только Оберон.NET) может использоваться и в условиях, не допускающих JIT-компиляцию в момент загрузки (хотя сама эта техника "докомпиляции" при загрузке, кажется, именно в Обероне и появилась: в OMI — Oberon Module Interchange — для переносимости модулей из одной среды в другую).
    Возможно, поэтому дженерики и не входят в состав языка Оберон, что могут быть применены не везде. (Хотя до конца это мне неясно.)
    Ущерб здесь не для функциональности Оберона, а для статического контроля типов, на что обращалось внимание.
    Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 11.02.05 09:46
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Cyberax, Вы писали:


    C>>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных

    C>>ОС. Еще рекомендую почитать про O(1) планировщики.

    СГ>spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).


    С точки зрения embedded программирования для устройсвт с небольшой производительностью оберон плохо применим. Ему ран-тайм нужен в обязательном порядке (тлт можно без него? хотя сомнеаваюсь). А если на не нужны ни активный объекты, ни сборщики мусора (для большого количества встроенных приложения можно вообще статически данные выделять), то зачем платить памятью и производительностью за этот ран-тайм. А минимальной ядро для организации параллельных вычислений и синхронизации можно втиснуть в несколько сотен байт или пару килобайт
    Re[62]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 11.02.05 10:37
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Serginio1, Вы писали:


    AVC>>>Но там требовалась JIT компиляция.

    S>> Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).

    AVC>Спасибо, я и правда почему-то в этот момент забыл, что в .NET все подвергается JIT.

    AVC>А хотел я сказать, что Оберон (как язык в целом, а не только Оберон.NET) может использоваться и в условиях, не допускающих JIT-компиляцию в момент загрузки (хотя сама эта техника "докомпиляции" при загрузке, кажется, именно в Обероне и появилась: в OMI — Oberon Module Interchange — для переносимости модулей из одной среды в другую).
    AVC>Возможно, поэтому дженерики и не входят в состав языка Оберон, что могут быть применены не везде. (Хотя до конца это мне неясно.)
    AVC>Ущерб здесь не для функциональности Оберона, а для статического контроля типов, на что обращалось внимание.
    AVC>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".
    А почему нв ВЫ?????
    На самом деле дженерики это очень хороший подход. Впринципе давно существует понятие универсальный промежуточный язык, с последующей компиляцией в натив. MSIL как раз такой язык полностью типизированный и с метатаданными. Дженерики тоже хранятся в MSIL и легко типизируются.
    Из этой длинющей ветки понял, что оберон по своей сути мало отличается от манагед сред, правда со своими особенностями.
    Джнерики только появились пока в бетта версиях Net и Java и развиваются и появятся они наверняка и в Обероне
    Так или иначе все наработки так и на голом месте ничего не вырастает.
    Опять же если смотреть на Net то есть как обычный фреймворк так и компакт фреймворк для КПК. Наверняка найдется и область применения и для Оберон систем более широкое. И это прекрасно, что прогресс двигают не только промышленные монстры, которые правда больше заимствуют чем изобретают. И для совершенства нет предела.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 11.02.05 10:44
    Оценка:
    AVC пишет:

    > Д>А где сейчас те языки, операционки и вертолеты?

    > По-моему об этом уже достаточно много говорили.
    > Видимо, подтекст такой, что сейчас это не используется?

    Используется, но не широко.

    > Это не так.

    > Паскаль используется.

    В основном для обучения (для чего он замечательно подходит, кстати говоря).

    > Модула-2 используется в космической промышленности (кстати, в том

    > числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
    > Оберон-2 используется, например, в NASA.

    Кем? Можете сказать в каких аппаратах был использован Оберон?

    > Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.


    Они появились в Обероне далеко не впервые.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 10:55
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Ну я особо не вникал в код , интересно было посмотреть как там низкоуровневый аспекты реализованы, оказалось на асме (ну по другому никак). Только имхо, встроенный ассемблер — не очень удачное решение, проще отдельный ассемблер, переносить код на другие архитектуры лучше будет.


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

    СГ>>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.

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

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[13]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 11.02.05 11:09
    Оценка:
    Здравствуйте, AVC, Вы писали:

    СГ>>>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.

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

    AVC>На Обероне можно отследить использование низкоуровневых конструкций.

    AVC>Даже просто не разрешить загрузку модулей, использующих такие конструкции, если так критична будет защита.
    AVC>Как и в Модуле, низкоуровневые конструкции требуют специального импорта (SYSTEM), который нельзя скрыть. (В отличие от использования низкоуровневых конструкций в Си. Хотя, впрочем, в Си почти все конструкции низкоуровневые. )

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

    Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код на встроенном ассемблере? Для этого нужно испортирование какого-то модуля?
    MOV BX,<левый адрес>
    MOV [BX],<всякий мусор>
    Проехались по чужой памяти.

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

    Такая ситуация повалит всю систему, в системе с разделением памяти погибнет только один процесс.
    Re[63]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 11:35
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    AVC>>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".

    S> А почему не ВЫ?????

    Ну и я то же.
    На самом деле, до самого последнего времени я имел очень смутное представление о .NET (пока занимаюсь задачами, далекими от этого), и только сейчас понемногу "наверстываю упущенное".
    Весьма вероятно, иногда я "изобретаю велосипед".

    S> На самом деле дженерики это очень хороший подход. Впринципе давно существует понятие универсальный промежуточный язык, с последующей компиляцией в натив. MSIL как раз такой язык полностью типизированный и с метатаданными. Дженерики тоже хранятся в MSIL и легко типизируются.

    S> Из этой длинющей ветки понял, что оберон по своей сути мало отличается от манагед сред, правда со своими особенностями.
    S> Джнерики только появились пока в бетта версиях Net и Java и развиваются и появятся они наверняка и в Обероне
    S> Так или иначе все наработки так и на голом месте ничего не вырастает.
    S> Опять же если смотреть на Net то есть как обычный фреймворк так и компакт фреймворк для КПК. Наверняка найдется и область применения и для Оберон систем более широкое. И это прекрасно, что прогресс двигают не только промышленные монстры, которые правда больше заимствуют чем изобретают. И для совершенства нет предела.

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[64]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 11.02.05 11:44
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Serginio1, Вы писали:


    AVC>>>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".

    S>> А почему не ВЫ?????
    ЭНе много описался правильно читать А почему не ВЫ?????


    AVC>Мне очень нравится Оберон, я уже успел полюбить этот язык (хотя знаком с ним сравнительно недавно), но я не "фанат" Оберона, моя "приязнь" к нему вполне рациональна (как мне кажется ).

    Чувствуется. Для себя подчерпнул много нового.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[42]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 11:45
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Модула-2 используется в космической промышленности (кстати, в том

    >> числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
    >> Оберон-2 используется, например, в NASA.
    C>Кем? Можете сказать в каких аппаратах был использован Оберон?

    Информация такая (по памяти, немного спешу):
    Модула-2 используется в наших спутниках связи;
    конкретно в каких аппаратах NASA был применен Оберон сейчас сказать не могу.
    Могу сказать, какие изменения были внесены в стандарт Оберона по просьбе NASA.

    >> Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.

    C>Они появились в Обероне далеко не впервые.

    Вполне возможно, хотя их применение в комплексе (в каком они и представляют силу) до Оберона мне неизвестно.
    Правда, я не вполне понял Вашу мысль — какие идеи именно Вы имели в виду?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[11]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 11.02.05 11:45
    Оценка:
    Здравствуйте, AVC, Вы писали:


    AVC>В принципе, сам "рантайм" может быть написан на Обероне.


    Нет, сам рантайм может быть написан только на Обероне с применением встроенного ассемблера, в доказательство я уже приводил фрагменты кода ГолубойБутылки, т.е. протсто скомпилировать рантайм для нового железа нельзя, нужно его ПОРТИРОВАТЬ

    AVC>Он нужен для поддержки определенных свойств системы. Например, для поддержки сборки мусора.

    AVC>Если такие свойства не требуются, то можно обойтись и без него (в значительной мере или полностью — в зависимости от обстоятельств).

    Это как? Если я правильно понял, то объекты можно создавать только в куче управляемой сборщиком мусораю Если это не оспользовать, то где будут объекты, на стеке или глобальные? И что это будет за Оберон, это уже совсем другой язык (подрезанный С++)

    AVC>Действительно, многозадачность можно организовать очень простыми средствами, гораздо проще, чем делается обычно в операционках.

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

    Вы решили, что ее нет, потому что можно приводить типы? Это средство которое нужно правильно использовать. Лучше пусть будет что-то чте не всегдя следует использовать, чем не иметь совсем.

    AVC>Мой интерес к этой теме и возник из наблюдений за написанием и отладкой встроенного ПО. Для поддержки этого благородного дела я пишу компиляторы (Си), ассемблеры, отладчики и т.д. (Если честно, дело не слишком хитрое.)

    AVC>И все равно, остаются большие трудности. В силу того факта, что указатели в Си имеют слишком неопределенную природу (массив — указатель, malloc — указатель, выходной параметр — указатель), трудно организовать поддержку процесса отладки. (А когда дело доходит до отладки "по железу", то нервотрепка обеспечена.)

    А можно поподробнее про трудности (хотя чего может быть сложного в указателе )? Я имею некоторый опыт общения с втроенным ПО и основные трудности были связаны со всем чем угодно, но только не с использованием С. Кстати массив не указатель, правильнее сказать, что имя массива приводится к типу указателя на элемент массива, самого указателя не существует, только массив.


    AVC>В результате меня "заела совесть", и я стал искать другие подходы. Так и наткнулся на Оберон. (Хотя обязательно рассматриваю и другие возможности. Например, ребята подкинули ссылки по "надежному Си".)

    AVC>С Вашим выводом о неприменимости Оберона во встроенных устройствах я не согласен.

    Это было исключительно мое ИМХО

    AVC>Я даже рассматриваю его как язык-кандидат именно для этой цели.


    Подумайте еще раз о С в том контексте, что компиляторы языка С, существую практически для любых платформ
    Re[65]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 11:49
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

    AVC>>Мне очень нравится Оберон, я уже успел полюбить этот язык (хотя знаком с ним сравнительно недавно), но я не "фанат" Оберона, моя "приязнь" к нему вполне рациональна (как мне кажется ).

    S> Чувствуется. Для себя подчерпнул много нового.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[14]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 12:02
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код на встроенном ассемблере? Для этого нужно испортирование какого-то модуля?

    RRM>MOV BX,<левый адрес>
    RRM>MOV [BX],<всякий мусор>
    RRM>Проехались по чужой памяти.

    В принципе, Оберон, конечно — язык компилируемый, хотя возможна и докомпиляция на стадии загрузки модуля. В Обероне изначально был способ переносить код между разными Оберон-системами (OMI), который впоследствии стал известен как JIT.

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

    RRM>Такая ситуация повалит всю систему, в системе с разделением памяти погибнет только один процесс.

    Вопрос понятен и совершенно разумен.
    Я и правда сначала не понял, на чем Вы делаете акцент.
    Надо подумать...
    В принципе, когда-то у меня возникал подобный вопрос, но я тогда решил, что в системах, критичных с точки зрения безопасности, никто не даст редактировать исполняемые файлы. (Система может это запрещать?)
    А можно попробовать и другой способ. Например, проверять контрольную сумму на этапе загрузки, или еще что-нибудь.
    Главное, согласен — такую возможность нельзя упускать из виду.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[12]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 12:12
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Здравствуйте, AVC, Вы писали:



    AVC>>В принципе, сам "рантайм" может быть написан на Обероне.

    RRM>Нет, сам рантайм может быть написан только на Обероне с применением встроенного ассемблера, в доказательство я уже приводил фрагменты кода ГолубойБутылки, т.е. протсто скомпилировать рантайм для нового железа нельзя, нужно его ПОРТИРОВАТЬ

    Вы привели частный случай — это еще не доказательство.
    В действительности, я (на основании описания языка Оберон и его стандарта Oakwood guidelines) могу дать Вам слово (как де Лопиталь ), что рантайм может быть написан на самом Обероне. Все необходимые средства есть.

    AVC>>Если такие свойства не требуются, то можно обойтись и без него (в значительной мере или полностью — в зависимости от обстоятельств).

    RRM>Это как? Если я правильно понял, то объекты можно создавать только в куче управляемой сборщиком мусораю Если это не оспользовать, то где будут объекты, на стеке или глобальные? И что это будет за Оберон, это уже совсем другой язык (подрезанный С++).

    Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.
    Поэтому в языке и существуют явные указатели (в отличие от Java).

    Пока все, труба (т.е. начальство) зовет!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[13]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 11.02.05 12:29
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Вы привели частный случай — это еще не доказательство.

    AVC>В действительности, я (на основании описания языка Оберон и его стандарта Oakwood guidelines) могу дать Вам слово (как де Лопиталь ), что рантайм может быть написан на самом Обероне. Все необходимые средства есть.

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

    AVC>Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.

    AVC>Поэтому в языке и существуют явные указатели (в отличие от Java).

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

    А как создать объект на стеке?

    P.S. Про трудности с указателями мне все еще интересно
    Re[7]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 11.02.05 13:13
    Оценка:
    Здравствуйте, AVC, Вы писали:

    К>>>>Во-первых, вылететь из очереди планировщика можно тремя способами:

    К>>>>- из running в waiting
    К>>>>- из running в suspended
    К>>>>- из ready в suspended
    AVC>>>ИМХО, это зависит от ОС.
    AVC>>>Может быть три способа, а может быть тридцать три.
    К>>Интересно, это какие же тридцать три, если всего есть 5 принципиально разных состояний (выполняется, готов, усыплён, ждёт, завершён).

    AVC>Так это какими абстракциями пользоваться.

    AVC>Я, например, вижу только три состояния:
    AVC>1) текущий процесс (running по Вашему);
    AVC>2) процесс в очереди исполнения (ready);
    AVC>3) ждущий какого-нибудь внешнего события (waiting).
    AVC>Конечно, для последнего варианта можно насчитать множество разновидностей.
    AVC>Но процесс все равно находится в состоянии ожидания того светлого времени, когда его "разбудит" диспетчер.

    4) suspended (временно не планируемый) — но, как показывает практика, это зачастую опасно, да и не нужно (можно грамотно заменить на ожидание).

    AVC>>>Для обеспечения сохранности инвариантов существуют мониторы. (Или другие средства синхронизации.)

    AVC>>>Если система поддерживает мониторы, то неясно, почему могут быть нарушены (системные) инварианты.
    К>>Монитор, я так понимаю, не предполагает исключительное и непрерываемое исполнение программы? Или предполагает?!

    AVC>Монитор предполагает, что доступ к разделяемой переменной в любой момент времени может иметь не более одного процесса.


    Доступ — это явление, растянутое во времени. В минимальном объёме — это атомарное чтение/модификация. Но монитор обеспечивает атомарность всей транзакции, которая может быть довольно долгой (хотя, если она слишком долгая, то это баг).

    К>>- сборщик мусора знает о мониторе и честно ждёт (или просто обходит стороной) заблокированные данные; достаточно теперь зависнуть в мониторе (например, на взаимоблокировке или банальном бесконечном цикле) — и привет


    AVC>Если мониторы, связанные с управлением памятью, входят в состав ядра ОС, то зависание такого монитора равносильно зависанию ядра.

    AVC>А уж если ядро зависло — ничего не попишешь...

    Вот пример пользовательского монитора.
    class World { ... };
    
    synchronized class Hello
    {
      private World world;
      public Hello() {}
      public void longlive()
      {
        while(rand() != 12345)
          world = new World(); // занимаемся фигнёй, постоянно трогая переменную
      }
    };

    Спрашивается, что сделает GC, когда наступит пора проверить граф зависимостей объекта класса Hello?
    Либо ждать (до посинения), либо плюнуть.

    Конечно, в виртуальной машине Java все операции присваивания атомарны, поэтому сборщик может с чистой совестью обойти блокировку. Но в native коде это уже может быть не так...
    Впрочем, есть 3 простых способа
    — jit-компилятор пихает всюду хардверные блокировки (x86-инструкции LOCK, CLI/STI и т.п.)
    — он же расставляет в коде вызовы некой функции yield(), обеспечивая кооперативную многозадачность
    — кооперативность обеспечена в native-коде всех системных функций; предполагается, что в них будут заходить достаточно часто (примерно так это сделано в Windows 3.1)

    К>>- сборщик мусора не знает о мониторах и нагло копается в заблокированных данных, в том числе — на полудохлых


    AVC>Только, если существует единственный процесс.


    То есть?

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


    AVC>Зачастую вполне приемлимый вариант.

    AVC>Пара лишних операций на присваивание указателей все же эффективнее переключения контекста.

    К>>>>Во-вторых, вне зависимости от этого, сохраняется вопрос о легальности уничтожения ждущего объекта.

    AVC>>>Здесь нет ничего специфичного для ОС Оберон.
    AVC>>>На что, кстати, уже обращалось внимание.
    К>>А я и не говорю про Оберон. Просто в системах, где потоки — это низкий уровень, команду kill или TerminateThread применяют только от безысходности или по разгильдяйству. А если система сама будет решать, когда ей прибивать якобы заторможенный активный объект — будет много увлекательных приключений.

    AVC>О, искусственный интеллект!


    Вот и я про то же. Система априори решает "а ну их нафиг!" Пусть программер обеспечивает завершимость потоков.
    И если программер ошибётся... никакие красивые слова про GC, безопасный язык и т.п. не помогут.

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

    К>>>>То ли этот объект зацеплен за очередь к ресурсу, то ли его оттуда можно смело выдёргивать.

    AVC>>>Откуда?
    AVC>>>Вопрос неясен.
    К>>Откуда: из очереди к ресурсу.

    AVC>Тогда объект все же зацеплен за очередь к ресурсу.

    AVC>В чем дилемма?

    В том, что ресурсу от ждущего объекта ничего не надо. Одним в очереди больше, одним меньше — какая разница. Фактически, это ресурс зацеплен за объекта, а не объект — за ресурс.

    Поэтому, если объект встал в ожидание, то его можно (с оговорками, разумеется) изъять и уничтожить, как если бы он был висячим.
    Но если очередь ожидания унифицирована с другими очередями — то формально объект не висит, на него есть ссылки извне.

    AVC>>>А как он это сделает в условиях нескольких адресных пространств?

    К>>Процесс, выжравший свою квоту (или все ресурсы, если квота бесконечна), получит звоночек. Если звоночек не обработан, то процесс уничтожается, освобождая ресурсы. Остальные процессы при этом не страдают.

    AVC>То же самое, ИМХО, возможно и при едином адресном пространстве.


    ... пока процессы не начнут расшаривать память.
    Да, можно сказать: ты лазишь сюда, ты вот сюда, тефтели с рисом, меняться нельзя. Просто в условиях раздельных АП эту конвенцию легче соблюсти, все шары учитываются системой.
    Перекуём баги на фичи!
    Re[14]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 13:18
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Давайте для дальнейшей беседы четко определимся что значит "на самом Обероне". В это понятие вкладывается "Оберон и встроенный ассемблер" или "только Оберон без встроенного ассемблера"

    RRM>Дальше, мы обсуждаем ран-тайм который работает на голом железе? Или например под Виндой тоже. Давайте обсуждать случай работы на голом железе, если я правильно понял он интересен нам обоим

    Я имею в виду именно сам Оберон, без встроенного ассемблера, но с использованием псевдомодуля SYSTEM.
    И меня интересует работа по голому железу. (Предположим, нет ничего, написанного не на Обероне. Хотя, например, даже для компилятора Си я предоставляю встроенный ассемблер, чтобы использовать некоторые возможности аппаратуры, не поддерживаемые напрямую языком. Например, сумматор MAC.)

    AVC>>Хотя Оберон безусловно тяготеет к созданию объектов в куче, их можно создавать и статически, и на стеке.

    AVC>>Поэтому в языке и существуют явные указатели (в отличие от Java).
    RRM>С обероном сильно не знаком, но что-то мне подсказывает, что объекты на стеке это не оттуда. Сразу возникает пролема возврата указателей на временный объект и т.п. Тут писали, что объект можно создавать с помощью
    RRM>NEW(P)
    RRM>где P -указатель на создаваемый объект или как-то так, хотя надо еще где-то указать тип
    RRM>А как создать объект на стеке?

    Это просто запись.
    TYPE Object: RECORD ... END;
    VAR staticObject: Object;
    PROCEDURE foo;
    VAR objectOnStack: Object;
      p: POINTER TO Object;
    BEGIN
      NEW(p); (* объект в куче *)
    END foo;


    RRM>P.S. Про трудности с указателями мне все еще интересно


    OK!
    Сейчас я, увы, не смогу ответить (должен уйти).
    Но при первой возможности (правда, может быть, не сегодня) отвечу.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[8]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 11.02.05 13:21
    Оценка:
    Здравствуйте, Кодт,

    я отвечу позднее. Сегодня не успеваю.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[9]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 11.02.05 13:32
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>я отвечу позднее. Сегодня не успеваю.


    окей.
    Перекуём баги на фичи!
    Re[39]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 14.02.05 07:00
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Privalov, Вы писали:


    P>>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.


    AVC>Т.е. если надо долбить стену... ;)


    ... то нужно для этого выбрать подходящий инструмент.

    AVC>Шутка. :)


    Смеюсь...

    P>>Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.


    AVC>Кажется, Страуструп создал Cfront.

    AVC>Возможно, впоследствии написал компилятор для ранней версии Си++.
    AVC>Но вряд ли Вы будете утверждать, что какой-нибудь из современных компиляторов Си++ написан лично Страуструпом.

    Разумеется, не буду.

    AVC>Думаю, полезно было бы, если бы автор языка самолично писал (и переписывал, если в язык внесены изменения) его компилятор.

    AVC>Уверен, что качество языков повысилось бы. :)

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


    AVC>Вирт стремится создать надежный (а не идеальный) язык программирования.

    AVC>Одна из причин такого его желания изложена здесь:
    AVC>http://www.inr.ac.ru/~info21/info/wirth_avia.htm
    AVC>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.
    AVC>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
    AVC>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

    Вирт, создавая очередной язык программирования, выбрасывает в мусор все, сделанное ранее. Кроме своих идей, разумеется. Не он ли призывал всех бросить Паскаль и перейти на Модулу-2? Он нигогда не спрашивал, сколько стоит такой переход.

    AVC>Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.

    AVC>Да и тот давно уже создается огромным комитетом...

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

    У Страуструпа речь идет только о С++. Но посмотрите, какой объем информации. Можно проследить все основные направления развития как самого языка, так и проектов, на нем реализуемых.

    AVC>Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.


    А на чем эта поддержка основана? Разве Bell Labs когда-нибудь была благотворительной конторой? Поддержка со стороны Bell Labs означает, что наряду с внедрением новых идей и методов программирования остается возможность использования старого, проверенного временем и пользователями, матобеспечения. То есть, сохранение капиталовложений. ("Старого" не означает "устаревшего", разумеется. Матобесбечение вряд ли может считаться устаревшим, если оно удовлетворяет требованиям заказчика.)


    P. S.
    И, кстати, совершенно случайно нашел я "Астрономию на персональном компьютере", и даже успел ее просмотреть.
    Здесь
    Автор: AVC
    Дата: 07.02.05
    Вы цитировали абзац оттуда:

    Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.


    Вы, видимо, не слишком внимательно прочли предыдущий абзац, в котором авторы объясняют, почему они все-таки выбрали C++, и несколько последующих. Мог бы процитировать, но этот самый предыдущий абзац раза в 4 длиннее, не говоря уже о последующих. К тому же сейчас этой книги нет под рукой, а цитировать по памяти — неблагодарное занятие.

    А книжка действительно интересная, спасибо еще раз за название.
    Re[40]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 11:43
    Оценка:
    Здравствуйте, Privalov, Вы писали:

    AVC>>Здравствуйте, Privalov, Вы писали:

    P>>>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.
    AVC>>Т.е. если надо долбить стену...
    P>... то нужно для этого выбрать подходящий инструмент.
    AVC>>Шутка.
    P>Смеюсь...

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

    AVC>>Думаю, полезно было бы, если бы автор языка самолично писал (и переписывал, если в язык внесены изменения) его компилятор.

    AVC>>Уверен, что качество языков повысилось бы.
    P>Не обязательно хороший архитектор должен быть хорошим каменщиком.
    P>В программировании — то же самое. Кстати, в проекте, в котором я сейчас работаю, если бы его главный архитектор не садился сам за реализацию своих идей, нашей команде было бы гораздо легче жить.

    Не уверен, что метафора об архитекторе и каменщике применима к области ПО.

    AVC>>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.

    P>Вирт, создавая очередной язык программирования, выбрасывает в мусор все, сделанное ранее. Кроме своих идей, разумеется. Не он ли призывал всех бросить Паскаль и перейти на Модулу-2? Он нигогда не спрашивал, сколько стоит такой переход.

    А сколько, интересно, стоит такой переход?
    Вот что я вижу: для каждого приличного языка существует (библиотечная) поддержка практически всех известных алгоритмов. И возникает такая поддержка очень быстро.
    Кроме того, существует множество конверторов с языка на язык.
    (Некоторое исключение из этого правила составлял, пожалуй, лишь Фортран.)

    AVC>>Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.

    AVC>>Да и тот давно уже создается огромным комитетом...
    P>А Вы сравните страницу Вирта и страницу Страуструпа. У Вирта описаны полтора десятка проектов, каждый одним абзацем. О дальнейшей судьбе этих проектов на странице ничего не говорится.
    P>У Страуструпа речь идет только о С++. Но посмотрите, какой объем информации. Можно проследить все основные направления развития как самого языка, так и проектов, на нем реализуемых.

    Я так понимаю, Вы затрудняетесь похвастаться успехами Страуструпа в практическом программировании.
    Количество проектов отражает популярность языка, его поддержку заинтересованными организациями. Но отражает ли качество языка?

    AVC>>Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.

    P>А на чем эта поддержка основана? Разве Bell Labs когда-нибудь была благотворительной конторой? Поддержка со стороны Bell Labs означает, что наряду с внедрением новых идей и методов программирования остается возможность использования старого, проверенного временем и пользователями, матобеспечения. То есть, сохранение капиталовложений. ("Старого" не означает "устаревшего", разумеется. Матобесбечение вряд ли может считаться устаревшим, если оно удовлетворяет требованиям заказчика.)

    Вообще-то, ИМХО, со стороны Bell Labs против Вирта велась "необъявленная война".
    Вспоминаю впечатляющую статью Кернигана "Why Pascal is not my favorite programming language". Явно статья отражает негативные эмоции Кернигана о переписывании на Паскале ряда алгоритмов (для совместной книги с Плоджером). А скрыто — тот факт, что еще за два года до его статьи появился компилятор Модулы-2, языка, в котором все существенные недостатки Паскаля были Виртом уже устранены.
    Такой язык был уже опасен для Си. Именно с этого момента представители Bell Labs начали "педалировать" недостатки Паскаля, умалчивая о Модуле (хороший психологический прием). Например, Пайк в интересной статье о стиле программирования на Си дважды упоминает Паскаль. Оба раза — в словосочетании "tyranny of Pascal".
    Т.е. всячески внушалась мысль, что Вирт не может создать практического языка программирования.
    Какова же ценность этой критики?
    Рассмотрим один из пунктов кернигановской критики. Керниган пишет, что крупным недостатком Паскаля является то, что размерность входит в тип массива.
    Уже в это время в Модуле это было не так.
    Но идем дальше. В Обероне есть многомерные гибкие массивы. А что же в современном ему Си++ (хотя Си++ до сих пор не может прекратить экстенсивного роста)?
    Все как раньше в Си: размерности всех измерений, кроме первого, входят в тип массива.

    P>P. S.

    P>И, кстати, совершенно случайно нашел я "Астрономию на персональном компьютере", и даже успел ее просмотреть.
    P>Здесь
    Автор: AVC
    Дата: 07.02.05
    Вы цитировали абзац оттуда:

    P>

    P>Здесь надо сказать, что по сравнению с другими языками C++ имеет много недостатков, которые затрудняют разработку сложных научных программ. В частности, у него слабая поддержка одномерных и многомерных массивов, нет локальных процедур, неудачная концепция модуля, не поддерживается проверка индексов массивов, а также выполняется неконтролируемое преобразование типов.

    P>Вы, видимо, не слишком внимательно прочли предыдущий абзац, в котором авторы объясняют, почему они все-таки выбрали C++, и несколько последующих. Мог бы процитировать, но этот самый предыдущий абзац раза в 4 длиннее, не говоря уже о последующих. К тому же сейчас этой книги нет под рукой, а цитировать по памяти — неблагодарное занятие.

    Книги под рукой прямо сейчас нет.
    Читал я, однако, достаточно внимательно.
    Так что помню, говорилось о "гибкости и мощности" языка, а главное — о доступности компиляторов. (Хотя ко времени выхода книги еще не существовало компиляторов Си++, соответствующих стандарту. Это по оценкам знатоков Си++.)
    А потом — процитированный мной абзац, делающий бессмысленными (ИМХО) все предыдущие славословия.

    P>А книжка действительно интересная, спасибо еще раз за название.


    Welcome!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 11:59
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Рассмотрим один из пунктов кернигановской критики. Керниган пишет, что крупным недостатком Паскаля является то, что размерность входит в тип массива.

    AVC>Уже в это время в Модуле это было не так.

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

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[15]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 12:06
    Оценка:
    AVC>Здравствуйте, RailRoadMan, Вы писали:

    RRM>>P.S. Про трудности с указателями мне все еще интересно


    Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
    void foo(int *p)
    {
        p[4] = 21; /* как узнать - массив p или нет? */
        p++;
    }
    или
    void foo(int *p)
    {
        free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
    }

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 14.02.05 12:53
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Может быть, в таком случае стоило остановиться на Фортране?


    Многие так и делают, если переход себя не оправдывает. Но если оправдывает — старый язык бросают без сожалений.
    Переход на Модулу себя не оправдывал.

    AVC>В конце концов, это ведь всего лишь разновидность компиляции.


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

    AVC>Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально.


    Ты хочешь сказать, что они (эти самые фирмы) намеренно портят людям здоровье?

    AVC>Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована.

    AVC>Но его языки были бы хуже.
    AVC>Например, были бы такими же как Си++.

    Это ты тоже очень ловко ввернул.
    Оберонам до старичка С++ — как до Пекина раком, даже при всех его недостатках.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[43]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 13:00
    Оценка:
    AVC пишет:

    > AVC>>А *сколько*, интересно, стоит такой переход?

    > Д>сравнимо со стоимостью полной разработки заново
    > Может быть, в таком случае стоило остановиться на Фортране?

    Интересно, почему же большую часть научного софта до сих пор на нем
    пишут?

    > Д>Если бы Вирт потратил хоть небольшую часть времени не на размножение

    > бесконечных несовместимых вариаций и диалектов, а на заботу о
    > совместимости и/или интеропе — глядишь, его творениями и пользовались
    > бы сейчас. Когда говорят про его "непрактичность" и "оторванность от
    > жизни" — говорят именно про это.
    > Д>Какими будут контр-аргументы?
    > Если бы Вирт работал на крупную фирму, то "практичность" его творений
    > была бы гарантирована.
    > Но его языки были бы хуже.

    Понимаете, даже у того же Оберона есть _практические_ недостатки:
    1. Нет единой спецефикации для модулей расширения. (для _практического_
    использования — абсолютно критично).
    2. GC консервативный, а сам язык не особо подходит для точного GC.
    Аналог такого кода:
    SomeObject *obj=new SomeObject();
    static int ref=(int)obj;

    вызовет _утечку_ _памяти_.
    3. Нет интероперабельности GC и кода расширений (следует из 2).
    и т.д.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[16]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 14.02.05 13:23
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
    AVC>void foo(int *p)
    AVC>{
    AVC>    p[4] = 21; /* как узнать - массив p или нет? */
    AVC>    p++;
    AVC>}
    или
    void foo(int *p)
    AVC>{
    AVC>    free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
    AVC>}


    Пожалуй, тут просто необходимо ввести такое понятие, как домен (область определения) указателя.
    Уточнение происходит следующим образом (извините за корявость изложения идеи)
    модель "Указатель" / "Ссылка" (можно разыменовывать)
     <- модель "Указатель на тип T" (результат разыменования - объект T)
         <- тип T*, some_container::iterator и т.п.
             <- домен "объект в динамической памяти", "объект-агрегат", (статический, стековый, член, элемент массива)
                 <- домен "элемент конкретного массива" (или одиночный элемент), "голова массива", "хвост массива", ноль

    В скриптовых языках ограничиваются моделью "указатель".
    В С/С++ — типом указателя.
    В Обероне — доменом "динамический/статический", получая разные типы.

    Наверное, при желании можно детализировать, хотя бы различая голову, середину и хвост массива.
    тип        допустимые приведения    пример инициализации   функциональность
    
    new_array  >-+                  <-- p1 = new T[10];        можно применять delete[] p1;
                 |
    new_object   | >-+              <-- p2 = new T;            можно применять delete p2;
                 |   |
                 |   |
    array_ptr  <-+   | >-+          <-- T arr[10]; p3 = arr;   можно применять адресную арифметику и разыменовывать
                 |   |   |              p3=p1; p3=p3+4;
                 |   |   |
    object_ptr <-+ <-+ <-+ >-+      <-- T var; p4 = &var;      можно разыменовывать
                 |   |   |   |
    range_ptr  <-+   | <-+   | >-+  <-- ptr=arr+n; ptr=&var+1; можно применять арифметику, но не разыменовывать
                 |   |   |   |   |
    match_ptr  <-+ <-+ <-+ <-+ <-+  <-- ptr = NULL;            можно проверять на равенство

    Трактовка одиночных объектов как одноэлементных массивов — от неё можно безболезненно избавиться.

    В С++, чтобы к такой схеме придти, нужно налепить разных умных указателей и придерживаться конвенции — оборачивать все источники (new, new[], &) в соответствующие умные типы.
    В новых языках — можно вынести на уровень языка (или, если это клон С++, заставить соответствующие выражения возвращать правильный тип).

    Причём, обратите внимание: абстрагируясь от голого указателя, мы получаем возможность вводить любую рантайм-проверку и разные бонусы:
    — проверять совпадение доменов при сравнении и адресной арифметике
    — проверять выход за пределы домена при адресной арифметике и разыменовании
    — находить границы домена
    — реализовать сборку мусора (поскольку для каждого указателя можно найти голову блока, на середину которого он указывает; даже если этот блок — не массив, а структура)
    Перекуём баги на фичи!
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Трурль  
    Дата: 14.02.05 13:28
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Понимаете, даже у того же Оберона есть _практические_ недостатки:

    Ну, так "нет в мире совершенства".

    C>2. GC консервативный, а сам язык не особо подходит для точного GC.

    GC не консервативный (точнее, почти не консервативный).
    C>Аналог такого кода:
    SomeObject *obj=new SomeObject();
    static int ref=(int)obj;

    C>вызовет _утечку_ _памяти_.
    Именно _такого_ — не вызовет.
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 13:37
    Оценка:
    Трурль пишет:

    > C>2. GC консервативный, а сам язык не особо подходит для точного GC.

    > GC не консервативный (точнее, почти не консервативный).

    Да, ошибся. Объекты в куче он считает точными (это не сложно), а вот
    стек — консервативен.

    > C>Аналог такого кода:

    >
    >SomeObject *obj=new SomeObject();
    >static int ref=(int)obj;
    >
    > C>вызовет _утечку_ _памяти_.
    > Именно _такого_ — не вызовет.

    А если убрать static, то вызовет (до выхода из стекового фрейма)

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 14:30
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>Может быть, в таком случае стоило остановиться на Фортране?

    Д>Многие так и делают, если переход себя не оправдывает. Но если оправдывает — старый язык бросают без сожалений.
    Д>Переход на Модулу себя не оправдывал.

    Возможно. Важны факторы, принимаемые во внимание.
    Вы, часом, — не консервативный гегельянец, не полагаете, что "все разумное — действительно, все действительное — разумно"?

    AVC>>В конце концов, это ведь всего лишь разновидность компиляции.

    Д>С таким же успехом можно сказать, что процесс обычной компиляции — это и есть процесс производства программных продуктов. И за ненадобностью отменить программистов

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

    AVC>>Угу. Например, у крупных фармацевтических фирм свои представления о том, какое здоровье у людей им (этим фирмам) желательно. И ведь не подкопаешься — все рационально.

    Д>Ты хочешь сказать, что они (эти самые фирмы) намеренно портят людям здоровье?

    Да.
    Т.к. я многодетный отец , то этот вопрос для меня не праздный.
    Плюс — у моей жены есть медицинское образование.

    AVC>>Если бы Вирт работал на крупную фирму, то "практичность" его творений была бы гарантирована.

    AVC>>Но его языки были бы хуже.
    AVC>>Например, были бы такими же как Си++.
    Д>Это ты тоже очень ловко ввернул.
    Д>Оберонам до старичка С++ — как до Пекина раком, даже при всех его недостатках.

    "Тешь себя, тешь себя" (поглаживает) (с) "Ирония судьбы"

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 14:37
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> AVC>>А *сколько*, интересно, стоит такой переход?

    >> Д>сравнимо со стоимостью полной разработки заново
    >> Может быть, в таком случае стоило остановиться на Фортране?
    C>Интересно, почему же большую часть научного софта до сих пор на нем
    C>пишут?

    Ну, так именно это я и имел в виду.
    Зачем Си++?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 14:38
    Оценка:
    AVC пишет:

    >>> AVC>>А *сколько*, интересно, стоит такой переход?

    >>> Д>сравнимо со стоимостью полной разработки заново
    >>> Может быть, в таком случае стоило остановиться на Фортране?
    > C>Интересно, почему же большую часть научного софта до сих пор на нем
    > C>пишут?
    > Ну, так именно это я и имел в виду.
    > Зачем Си++?

    Для тех, кому надоело писать софт на Фортране.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[44]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 14.02.05 14:42
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>В конце концов, это ведь всего лишь разновидность компиляции.


    Д>С таким же успехом можно сказать, что процесс обычной компиляции — это и есть процесс производства программных продуктов. И за ненадобностью отменить программистов


    Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 14:44
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >>>> AVC>>А *сколько*, интересно, стоит такой переход?

    >>>> Д>сравнимо со стоимостью полной разработки заново
    >>>> Может быть, в таком случае стоило остановиться на Фортране?
    >> C>Интересно, почему же большую часть научного софта до сих пор на нем
    >> C>пишут?
    >> Ну, так именно это я и имел в виду.
    >> Зачем Си++?
    C>Для тех, кому надоело писать софт на Фортране.

    Понимаю.
    А как же совместимость?
    (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 14:48
    Оценка:
    AVC пишет:

    >>> Ну, так именно это я и имел в виду.

    >>> Зачем Си++?
    > C>Для тех, кому надоело писать софт на Фортране.
    > Понимаю.
    > А как же совместимость?
    > (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)

    Так вот поэтому ВСЕ и не переписывают

    Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума
    совместимости. И в этом он вполне преуспел.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[48]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 14:59
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >>>> Зачем Си++?

    >> C>Для тех, кому надоело писать софт на Фортране.
    >> Понимаю.
    >> А как же совместимость?
    >> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)
    C>Так вот поэтому ВСЕ и не переписывают

    Тут не вполне ясно.
    Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить совместимость?
    В общем, не понял.

    C>Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума

    C>совместимости. И в этом он вполне преуспел.

    Да ужъ... (Хотя, кажется, комитет по стандартизации Си не так озабочен совместимостью с Си++. Страуструп жалуется. Хотя еще надеется.)
    Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что Си", то возникает следующий вопрос: "Зачем Си?"
    Зачем вообще что-то кроме Фортрана, если уж так важна совместимость?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[49]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 15:09
    Оценка:
    AVC пишет:

    >>> А как же совместимость?

    >>> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)
    > C>Так вот поэтому ВСЕ и не переписывают
    > Тут не вполне ясно.
    > Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить
    > совместимость?

    Да, много фортрановского софта не переписывают на другие языки из-за
    библиотек.

    > C>Вообще, С++ создавался как ОО-расширение для С, с сохранением максимума

    > C>совместимости. И в этом он вполне преуспел.
    > Да ужъ... (Хотя, кажется, комитет по стандартизации Си не так озабочен
    > совместимостью с Си++. Страуструп жалуется. Хотя еще надеется.)

    Это уже из "современной истории"

    > Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что

    > Си", то возникает следующий вопрос: "Зачем Си?"

    Потому что на нем к середине 80-х годов было уже написана и работала
    большая часть софта.

    > Зачем вообще что-то кроме Фортрана, *если уж так важна совместимость*?


    Не весь софт изначально делался на Фортране.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: prVovik Россия  
    Дата: 14.02.05 15:15
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>В C# на уровне синтаксиса поддерживаются только 0-based размерности.

    И правильно. Ибо нефиг
    ... << RSDN@Home 1.1.4 @@subversion >>
    лэт ми спик фром май харт
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 14.02.05 16:13
    Оценка:
    Serginio1,

    > Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд


    Я недавно экспериментировал с этим делом. Например, на C++/CLI сделал индексированное свойство, возвращающее managed pointer. Reflector это дело честно в C# отобразил, дописав в возвращаемом значении ref. Но это же не значит, что на C#, действительно, можно так писать (в частности, это индексированное свойство C# "потреблять" отказался)
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[17]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 16:32
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    AVC>>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
    AVC>>void foo(int *p)
    AVC>>{
    AVC>>    p[4] = 21; /* как узнать - массив p или нет? */
    AVC>>    p++;
    AVC>>}
    или
    void foo(int *p)
    AVC>>{
    AVC>>    free(p); /* указывет p на объект кучи, или это адрес переменной в стеке или сегменте данных? */
    AVC>>}

    К>Пожалуй, тут просто необходимо ввести такое понятие, как домен (область определения) указателя.
    К>Уточнение происходит следующим образом (извините за корявость изложения идеи)
    К>
    К>модель "Указатель" / "Ссылка" (можно разыменовывать)
    К> <- модель "Указатель на тип T" (результат разыменования - объект T)
    К>     <- тип T*, some_container::iterator и т.п.
    К>         <- домен "объект в динамической памяти", "объект-агрегат", (статический, стековый, член, элемент массива)
    К>             <- домен "элемент конкретного массива" (или одиночный элемент), "голова массива", "хвост массива", ноль
    К>

    К>В скриптовых языках ограничиваются моделью "указатель".
    К>В С/С++ — типом указателя.
    К>В Обероне — доменом "динамический/статический", получая разные типы.

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

    К>
    К>тип        допустимые приведения    пример инициализации   функциональность
    
    К>new_array  >-+                  <-- p1 = new T[10];        можно применять delete[] p1;
    К>             |
    К>new_object   | >-+              <-- p2 = new T;            можно применять delete p2;
    К>             |   |
    К>             |   |
    К>array_ptr  <-+   | >-+          <-- T arr[10]; p3 = arr;   можно применять адресную арифметику и разыменовывать
    К>             |   |   |              p3=p1; p3=p3+4;
    К>             |   |   |
    К>object_ptr <-+ <-+ <-+ >-+      <-- T var; p4 = &var;      можно разыменовывать
    К>             |   |   |   |
    К>range_ptr  <-+   | <-+   | >-+  <-- ptr=arr+n; ptr=&var+1; можно применять арифметику, но не разыменовывать
    К>             |   |   |   |   |
    К>match_ptr  <-+ <-+ <-+ <-+ <-+  <-- ptr = NULL;            можно проверять на равенство
    К>

    К>Трактовка одиночных объектов как одноэлементных массивов — от неё можно безболезненно избавиться.

    К>В С++, чтобы к такой схеме придти, нужно налепить разных умных указателей и придерживаться конвенции — оборачивать все источники (new, new[], &) в соответствующие умные типы.

    К>В новых языках — можно вынести на уровень языка (или, если это клон С++, заставить соответствующие выражения возвращать правильный тип).

    К>Причём, обратите внимание: абстрагируясь от голого указателя, мы получаем возможность вводить любую рантайм-проверку и разные бонусы:

    К>- проверять совпадение доменов при сравнении и адресной арифметике
    К>- проверять выход за пределы домена при адресной арифметике и разыменовании
    К>- находить границы домена
    К>- реализовать сборку мусора (поскольку для каждого указателя можно найти голову блока, на середину которого он указывает; даже если этот блок — не массив, а структура)

    В принципе, идея мне кажется разумной.
    Но что особенно радует в предлагаемом подходе — его простота.
    Правда, в Обероне таких проблем вообще нет. (Он просто грамотно сделан.)
    Но ведь это такой скучный язык.
    А вот Си++ — это романтика.
    Ну где еще можно "зацепить" один поток за стековую переменную другого потока? Такая прелесть!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[16]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 14.02.05 16:36
    Оценка:
    Здравствуйте, AVC, Вы писали:

    Честно говоря, я все еще не понял проблемы?

    AVC>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
    AVC>void foo(int *p)
    AVC>{
    AVC>    p[4] = 21; /* как узнать - массив p или нет? */
    AVC>    p++;
    AVC>}


    Он должен реагировать на эти конструкции, как это описано в стандарте (ну это в общем и без меня понятно).
    Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.

    Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?

    P.S. Возможно, что я что-то упускаю, но проблемы не вижу.
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 14.02.05 16:51
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Serginio1,


    >> Нетовский рефлектор достаточно хорошо декомпилирует MSIL код во многие нетовские языки. Так, то выбор только за промежуточным языком, AST итд


    ПК>Я недавно экспериментировал с этим делом. Например, на C++/CLI сделал индексированное свойство, возвращающее managed pointer. Reflector это дело честно в C# отобразил, дописав в возвращаемом значении ref. Но это же не значит, что на C#, действительно, можно так писать (в частности, это индексированное свойство C# "потреблять" отказался)


    Ну что то похожее же выдал.
    Ну он много чего не умеет.
    Например
     public static unsafe object Box(void* ptr, Type type)
    {
          if (type == null)
          {
                throw new ArgumentNullException("type");
          }
          if (!type.IsPointer)
          {
                throw new ArgumentException(Environment.GetResourceString("Arg_MustBePointer"), "ptr");
          }
          Pointer pointer1 = new Pointer();
          pointer1._ptr = ptr;
          pointer1._ptrType = type;
          return pointer1;
    }


    function Pointer.Box(ptr:  *; type: Type): TObject;
    var
          pointer1: Pointer;
    begin
          if (&type = nil) then
                raise ArgumentNullException.Create('type');
          if (not &type.IsPointer) then
                raise ArgumentException.Create(Environment.GetResourceString('Arg_MustBePointer'), 'ptr');
          pointer1 := Pointer.Create;
          pointer1._ptr := ptr;
          pointer1._ptrType := &type;
          begin
                result := pointer1;
                exit
          end
    end;




    А вообще то из С# можно сделать конфетку не уступающей по возможностям C++/CLI.
    Например поводу боксинга. Например в яве есть аналоги отбоксенных валуе типов начинающиеся с большой буквы, правда там нет структур.
    Мне например был бы приятен смнтаксис Delphi
        type
         PMyStruct = box MyStructSt
         PInt = box int;

    итд. Вообщето впечатление такое, что C# явно придерживается, о чем кстати возмущался Рихтер.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[17]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 16:54
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Честно говоря, я все еще не понял проблемы?

    AVC>>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
    AVC>>void foo(int *p)
    AVC>>{
    AVC>>    p[4] = 21; /* как узнать - массив p или нет? */
    AVC>>    p++;
    AVC>>}


    RRM>Он должен реагировать на эти конструкции, как это описано в стандарте (ну это в общем и без меня понятно).


    Т.е. никак.

    RRM>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.


    Программист — человек. Он может ошибаться.
    А вот что делать компилятору и отладчику?

    RRM>Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?


    В том виде, как она реализована в Си, она безусловно вредна.
    Я на эту тему уже много раз высказывался, и моя точка зрения не изменилась.
    Ясно, что когда-то проход по массиву с перемещением указателя, а не индексной переменной, был эффективным решением.
    Сейчас это уже не так (вспоминаю ассемблерный код, порожденный Watcom C++).
    Потребности в адресной арифметике совсем бы не оставалось, если бы алгоритмы STL не подхватили эту форму записи. (Опять же для совместимости, надо думать.)

    RRM>P.S. Возможно, что я что-то упускаю, но проблемы не вижу.


    А она есть.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[18]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 14.02.05 17:18
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Т.е. никак.


    Не "никак", а "дословно" — есть разница.

    RRM>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.


    AVC>Программист — человек. Он может ошибаться.

    AVC>А вот что делать компилятору и отладчику?

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

    RRM>>Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?


    AVC>В том виде, как она реализована в Си, она безусловно вредна.

    AVC>Я на эту тему уже много раз высказывался, и моя точка зрения не изменилась.
    AVC>Ясно, что когда-то проход по массиву с перемещением указателя, а не индексной переменной, был эффективным решением.
    AVC>Сейчас это уже не так (вспоминаю ассемблерный код, порожденный Watcom C++).
    AVC>Потребности в адресной арифметике совсем бы не оставалось, если бы алгоритмы STL не подхватили эту форму записи. (Опять же для совместимости, надо думать.)

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

    Или буффер куда данные попадают из аппаратуры через DMA.

    Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.
    Re[50]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 17:21
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:

    >>>> А как же совместимость?
    >>>> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.)
    >> C>Так вот поэтому ВСЕ и не переписывают
    >> Тут не вполне ясно.
    >> Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить
    >> совместимость?
    C>Да, много фортрановского софта не переписывают на другие языки из-за
    C>библиотек.

    В принципе, это не так страшно. Ведь к фортрановским библиотекам можно обращаться и из других языков. Например, из Си. Или из Оберона. (Что, опять же, показывает несостоятельность "теории совместимости".)

    >> Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что

    >> Си", то возникает следующий вопрос: "Зачем Си?"
    C>Потому что на нем к середине 80-х годов было уже написана и работала
    C>большая часть софта.

    Говорят, что большая часть софта была написана на Коболе.

    >> Зачем вообще что-то кроме Фортрана, *если уж так важна совместимость*?

    C>Не весь софт изначально делался на Фортране.

    Это лапидарное изречение вполне достойно пополнить томик Козьмы Пруткова.
    Изначально софт делался в машинных кодах.
    Но все же именно Фортран был первым "языком высокого уровня", если не ошибаюсь?
    И кода на нем немеренно.
    Значит, надо было хранить ему верность из соображений совместимости. (Я развиваю тезис, что виртовские языки плохи, т.к. несовместимы. Хотя каждый, кто пользовался компилятором XDS, знает, что, например, Modula-2 и Oberon-2 прекрасно совместимы.)
    Ан нет, не утерпели.
    Говорят — неудобно на нем писать нерасчетные программы.
    И поперли изо всех щелей — Лисп, Кобол и т.д.
    И сказали С++ные программисты, что это хорошо. А вот Оберон — плохо.
    Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют возможность использовать хоть сишный код, хоть фортрановский.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[51]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 14.02.05 17:27
    Оценка:
    AVC пишет:

    >>> Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить

    >>> совместимость?
    > C>Да, много фортрановского софта не переписывают на другие языки из-за
    > C>библиотек.
    > В принципе, это не так страшно. Ведь к фортрановским библиотекам можно
    > обращаться и из других языков. Например, из Си. Или из Оберона. (Что,
    > опять же, показывает несостоятельность "теории совместимости".)

    Ага, а еще можно в Формулу-1 играть на асфальтовом катке. Фортран
    оптимизирован под скоростные вычисления так, что его еще никто не
    обогнал, а такой мост съест всю скорость.

    >>> Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что

    >>> Си", то возникает следующий вопрос: "Зачем Си?"
    > C>Потому что на нем к середине 80-х годов было уже написана и работала
    > C>большая часть софта.
    > Говорят, что б*о*льшая часть софта была написана на Коболе.

    Он жил (и продолжает жить) в отдельном мире, не оказывая сильного
    влияния на остальной.

    > Говорят — неудобно на нем писать нерасчетные программы.

    > И поперли изо всех щелей — Лисп, Кобол и т.д.
    > И сказали С++ные программисты, что это хорошо. А вот Оберон — плохо.

    Именно.

    > Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют

    > возможность использовать хоть сишный код, хоть фортрановский.

    Без этой возможности XDS был бы полным нулем.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[19]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 14.02.05 17:31
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:



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


    RRM>Или буффер куда данные попадают из аппаратуры через DMA.


    RRM>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.

    Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше.
    Но зато есть контроль над массивом буфера.
    Например массивы тоже легко обходятся без указателей, при этом оптимизируется проход по массиву аля P++ с контролем границ не на каждом шагу а на этапе for.
    Другой пример легче использовать массив строк чем буффер строк разделенными 0

    Итд. Большую часть оптимизации можно доверить компилятору.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[20]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 14.02.05 17:37
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

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


    RRM>>Или буффер куда данные попадают из аппаратуры через DMA.


    S> Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше.

    Не очень понял при чем здесь сериализация А также кэш, память на которую отображены аппаратные регистры и буферы вообще должна быть объявлена некэшируемой (как привило).

    S> Но зато есть контроль над массивом буфера.

    Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?
    Re[19]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 17:39
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    AVC>>Т.е. никак.

    RRM>Не "никак", а "дословно" — есть разница.

    В данном случае стандарт Си никак не различает разные типы аргументов-указателей.
    Поэтому я и написал: "никак".

    RRM>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.

    AVC>>Программист — человек. Он может ошибаться.
    AVC>>А вот что делать компилятору и отладчику?
    RRM>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.

    Опаньки!
    Куда ему, компилятору.
    Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками?

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

    RRM>Или буффер куда данные попадают из аппаратуры через DMA.
    RRM>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.

    Никто не отрицает потребности в низкоуровневых средствах.
    Но нельзя же превращать весь язык в одно низкоуровневое средство!
    В Обероне есть четкое различие: "импорт" SYSTEM.
    А в Си низкоуровневые средства "заполонили" весь язык.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 14.02.05 17:44
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    S>> Но зато есть контроль над массивом буфера.

    RRM>Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?

    Хотелось бы уточнить, одинаково ли мы понимаем термин "адресная арифметика"?
    В Си так называют операции сложения/разности указателя с целым числом (результат — указатель) и разности указателей (результат — целое число).

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 14.02.05 17:50
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:


    S>> Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше.

    RRM>Не очень понял при чем здесь сериализация А также кэш, память на которую отображены аппаратные регистры и буферы вообще должна быть объявлена некэшируемой (как привило).
    Я имел ввиду такую ситуацию http://gzip.rsdn.ru/forum/?mid=556030
    Автор: Yury_Malich
    Дата: 02.03.04

    S>> Но зато есть контроль над массивом буфера.
    RRM>Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?
    То есть с массивом без адресной арифьетики некуда????
    Есть базовый адресс и размерность.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[20]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 14.02.05 17:51
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, RailRoadMan, Вы писали:


    RRM>>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.

    AVC>>>Программист — человек. Он может ошибаться.
    AVC>>>А вот что делать компилятору и отладчику?
    RRM>>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.

    AVC>Опаньки!

    AVC>Куда ему, компилятору.
    AVC>Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками?
    Нет не отрицаю, но при этом не вижу смысла забирать низкоуровневые возможности.

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

    RRM>>Или буффер куда данные попадают из аппаратуры через DMA.
    RRM>>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.

    AVC>Никто не отрицает потребности в низкоуровневых средствах.

    AVC>Но нельзя же превращать весь язык в одно низкоуровневое средство!
    AVC>В Обероне есть четкое различие: "импорт" SYSTEM.
    AVC>А в Си низкоуровневые средства "заполонили" весь язык.

    А С и разрабатывался как алтернатива ассеблеру. Кстати есть С++, и там вас никто не вынуждает использовать массивы, есть например vector<> + все нискоуровневые возможности С.

    Согласитесь, что вы не против адресной арифметики, а против ее повсеместного и неуместного применения.
    Еще мне кажется, что использование адресной арифметики в стиле С несколько проще, чем модуля SYSTEM (по крайне мере там, где это необходимо)
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 15.02.05 05:04
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Возможно. Важны факторы, принимаемые во внимание.


    и как ни странно, в число этих факторов никогда не входили такие параметры, как "чистота", "стройность" языка, и прочие спорные вещи

    AVC>Вы, часом, — не консервативный гегельянец, не полагаете, что "все разумное — действительно, все действительное — разумно"?


    вы, батенька, нецензурными словами не ругайтесь

    AVC>И какая, пардон, связь?

    AVC>Вас же не удивляет компиляция в машинный код?
    AVC>А теперь представьте себе, что какой-нибудь компьютер "понимает" Си++, Си или даже (вот ужас! ) Оберон.

    Связь в том, что просто перевод с одного языка на другой не даст тебе работающую программу. Это — ничтожно малая часть работы, а дьявол — он совсем в другом.
    Например, перенос программы с C++ под Windows на тот же C++, но под Linux — это очень большой объем работы. Странно, не правда ли?

    AVC>Т.к. я многодетный отец , то этот вопрос для меня не праздный.

    AVC>Плюс — у моей жены есть медицинское образование.

    А это уже смахивает на паранойю.

    AVC>"Тешь себя, тешь себя" (поглаживает) (с) "Ирония судьбы"


    Не смешите мои тапочки. Эта тема уже десять раз тут обсасывалась. Ключевые слова для поиска — "мощность языка"
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[51]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 15.02.05 05:08
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют возможность использовать хоть сишный код, хоть фортрановский.


    Угу. Только ко времени их появления Оберон уже благополучно скончался.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[41]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 15.02.05 06:39
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Я согласен, что хорошая голова — главное в любом деле. Но не согласен с подтекстом Вашего утверждения, что если голова хорошая, то и любой инструмент сойдет.


    AVC>Есть у Сутеева такая сказка — "Палочка-выручалочка". (Прошу прощения за детские ассоциации. Моему младшему — три, вот и штудируем "классиков". :) )

    AVC>Там в самом конце высказывается мысль, родственная Вашей: главное — умная голова и доброе сердце. Это, бесспорно, — главное. Но как бы ежик без этой палки зайца из болота вытянул и от волка спас? :xz:

    А если продолжить? Если мне жизненно необходимо сейчас отстрелить себе ногу?

    P>>Не обязательно хороший архитектор должен быть хорошим каменщиком.

    P>>В программировании — то же самое. Кстати, в проекте, в котором я сейчас работаю, если бы его главный архитектор не садился сам за реализацию своих идей, нашей команде было бы гораздо легче жить.

    AVC>Не уверен, что метафора об архитекторе и каменщике применима к области ПО.


    Есть опыт участия в двух подобных проектах. В первом случае архитектор и не пытался писать код. Он был банкиром. Тем не менее, ему удавалось координировать действия команд разработчиков так, что в итоге получился хорошо документированный и легкий в обслуживании пакет программ.
    Во втором случае архитектор не доверил реализацию своих замыслов никому. В результате сейчас приходится разбираться в процедурах по 1500 — 2500 строк с кучей GOTO, сотнями глобальных переменных и константами с именами ONE, TWO, ..., TWENTY, ... .

    AVC>А сколько, интересно, стоит такой переход?

    AVC>Вот что я вижу: для каждого приличного языка существует (библиотечная) поддержка практически всех известных алгоритмов. И возникает такая поддержка очень быстро.
    Она же не сама возникает. И в новой системе, несовместимой с предыдущими, не так уж и быстро. Фактически это означает создание с нуля всей операционной систены со всеми инструментальными средствами.

    AVC>Кроме того, существует множество конверторов с языка на язык.


    Отлично, пишем конвертор с C++ на Оберон. В качестве теста используем STL.

    AVC>(Некоторое исключение из этого правила составлял, пожалуй, лишь Фортран.)



    AVC>Вообще-то, ИМХО, со стороны Bell Labs против Вирта велась "необъявленная война". :)

    [....]

    Тогда обе стороны высыпали друг на друга достаточно гнилых помидоров. Но не будете же Вы всерьез утверждать, что Керниган заставлял разработчиков во всем мире использовать C, а не Модулу-2?
    И почему в 1990 г. из известных (рекламируемых) систем программирования была 1 Модула-2 (TopSpeed), и около 15 C/C++. Это что, тлетворное влияние Bell Labs?

    P>>P. S.


    AVC>Книги под рукой прямо сейчас нет.

    AVC>Читал я, однако, достаточно внимательно.
    AVC>Так что помню, говорилось о "гибкости и мощности" языка, а главное — о доступности компиляторов. (Хотя ко времени выхода книги еще не существовало компиляторов Си++, соответствующих стандарту. Это по оценкам знатоков Си++.)
    AVC>А потом — процитированный мной абзац, делающий бессмысленными (ИМХО) все предыдущие славословия.

    Не славословие, а обоснование принимаемого решения. не забываем, что авторы книги — не профессиональные программисты, а астрономы. Они не делали программный продукт. Они пытались переложить на машину рутинную работу, освободив себе время для творческой. В полном соответствии с принципом, провозглашенным IBM: "Машина должна работать, человек — думать".
    О недостатках языка, ИМХО, они сказали таким же, как они, математикам, физикам, астрономам.
    Программисты об этих недостатках знают, а "кто предупрежден — тот вооружен", не так ли?
    И, кстати, перешли они с надежного Паскаля на дефектный C...


    AVC>Welcome! :)
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 15.02.05 08:21
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >>SomeObject *obj=new SomeObject();

    >>static int ref=(int)obj;
    >>
    >> C>вызовет _утечку_ _памяти_.
    >> Именно _такого_ — не вызовет.

    C>А если убрать static, то вызовет (до выхода из стекового фрейма)


    Что Вы такое выдумываете! Нет, не вызовет!!!

    В переменной int ref хранится численное значение указателя obj взятое в момент выполнения операции присваивания int ref=(int)obj. В следующий момент времени, вообще говоря, численное значение указателя obj может быть любым другим т. к. сборщик мусора может переместить объект в другое место. Число хранящееся в целочисленной переменной int ref останется прежним, сборщика мусора это число не интересует. Если Вы когда-нибудь потом (после нескольких запусков GC) захотите превратить число int ref обратно в указатель — то этот указатель будет 100% повисшим.
    Re[45]: Нужна ли Оберон-ОС защита памяти?
    От: Privalov  
    Дата: 15.02.05 08:25
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Cyberax, Вы писали:


    >>> Может быть, в таком случае стоило остановиться на Фортране?


    C>>Интересно, почему же большую часть научного софта до сих пор на нем

    C>>пишут? ;)

    СГ>Тот софт для суперкомпьютеров, в то время как для PC научный софт пишут на модификации языка Oberon-2 под названием Component Pascal (http://www.inr.ac.ru/~info21/).


    Сколько в лаборатории матмоделирования работал (на PC), столько там Фортран и использовался.

    Что, для суперкомпьютеров реализаций Оберона не Существует? А что мешает?
    Re[18]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 15.02.05 09:05
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>В принципе, идея мне кажется разумной.

    AVC>Но что особенно радует в предлагаемом подходе — его простота.

    Добрая ирония
    На самом деле, я здесь просто глубже развил парадигму "доступ по указателю". Если развивать парадигму "доступ через функции", то получим другую картину.

    AVC>Правда, в Обероне таких проблем вообще нет. (Он просто грамотно сделан.)

    AVC>Но ведь это такой скучный язык.
    AVC>А вот Си++ — это романтика.

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

    Красивое развитие идеи указателей — это итераторы STL. Хотя с таким же, а то и с большим успехом можно было вместо итераторов ввести понятие "диапазон", и такие попытки делаются.

    Оберон — да, действительно скучный язык. Типизацией по пальцам надавал, размещением по пальцам надавал, а средств абстракции — не надавал

    AVC>Ну где еще можно "зацепить" один поток за стековую переменную другого потока? Такая прелесть!
    Перекуём баги на фичи!
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 15.02.05 09:54
    Оценка:
    Сергей Губанов пишет:

    >>>SomeObject *obj=new SomeObject();

    >>>static int ref=(int)obj;
    >>>
    >>> C>вызовет _утечку_ _памяти_.
    >>> Именно _такого_ — не вызовет.
    > C>А если убрать static, то вызовет (до выхода из стекового фрейма)
    > Что Вы такое выдумываете! *Нет, не вызовет!!!*
    > В переменной int ref хранится численное значение указателя obj взятое
    > в момент выполнения операции присваивания int ref=(int)obj. В
    > следующий момент времени, вообще говоря, численное значение указателя
    > obj может быть любым другим т. к. сборщик мусора может переместить
    > объект в другое место.

    А вот фигвам. GC в той реализации Оберона, которую я смотрел,
    обрабатывает стек консервативно. То есть любая последовательность байт
    на стеке, которая напоминает указатель — будет считаться указателем.
    Причем такие объекты, естественно, двигаться в куче никуда не будут.

    > Число хранящееся в целочисленной переменной int ref останется прежним,

    > сборщика мусора это число не интересует. Если Вы когда-нибудь потом
    > (после нескольких запусков GC) захотите превратить число int ref
    > обратно в указатель — то этот указатель будет 100% повисшим.

    А ты простестируй

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 15.02.05 10:02
    Оценка:
    Честно говоря, дальше с вам спорить не считаю нужным. Если вы помните, этот спор начался с того, что мне было интересно узнать про трудности с указателями. Я узнал, но не проникся, видимо мне они пока серьезных проблем не доставляли.

    Если вам по какой-то причине нужен оберон, хорошо, что он есть, мне Оберон не нужен, может пока, может вообще.

    P.S. Просто раздражает, когда Оберон (и иже с ними) выставляют в виде некой панацеи от всего. Но это не к вам.
    Re[23]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 15.02.05 10:38
    Оценка:
    Здравствуйте, RailRoadMan, Вы писали:

    RRM>Честно говоря, дальше с вам спорить не считаю нужным. Если вы помните, этот спор начался с того, что мне было интересно узнать про трудности с указателями. Я узнал, но не проникся, видимо мне они пока серьезных проблем не доставляли.


    Это совершенно нормально.
    На самом деле, дискуссии должны просто вести к лучшему взаимопониманию.
    (И нет никакой нужды доводить их до утрированных выводов вроде — X абсолютно прав, а Y окончательно и безнадежно неправ! Зачастую сам предмет и не допускает таких выводов.)

    RRM>Если вам по какой-то причине нужен оберон, хорошо, что он есть, мне Оберон не нужен, может пока, может вообще.


    OK.
    Я с самого начала говорил, что и не собираюсь лишать программистов их любимых инструментов.

    RRM>P.S. Просто раздражает, когда Оберон (и иже с ними) выставляют в виде некой панацеи от всего. Но это не к вам.


    Согласен, это может раздражать.
    Но, ради объективности, скажу, что некоторую "упертость" проявили обе стороны. (Я имею в виду обсуждение Оберона в целом. Увы, я и сам не исключение. )

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[46]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 15.02.05 14:51
    Оценка:
    Здравствуйте, Дарней, Вы писали:

    AVC>>Возможно. Важны факторы, принимаемые во внимание.

    Д>и как ни странно, в число этих факторов никогда не входили такие параметры, как "чистота", "стройность" языка, и прочие спорные вещи

    А также такие спорные вещи как "простота" и "корректность".

    AVC>>И какая, пардон, связь?

    AVC>>Вас же не удивляет компиляция в машинный код?
    AVC>>А теперь представьте себе, что какой-нибудь компьютер "понимает" Си++, Си или даже (вот ужас! ) Оберон.
    Д>Связь в том, что просто перевод с одного языка на другой не даст тебе работающую программу. Это — ничтожно малая часть работы, а дьявол — он совсем в другом.
    Д>Например, перенос программы с C++ под Windows на тот же C++, но под Linux — это очень большой объем работы. Странно, не правда ли?

    В свое время я писал приличное по размерам графическое приложение под Windows.
    Чтобы проверить, насколько я хорошо отделил представление от собственно модели, попросил товарища помочь с переносом под X-Windows (Linux).
    Весь перенос заключался в замене реализации нескольких графических классов и занял 2 часа.
    Странно, не правда ли?

    AVC>>Т.к. я многодетный отец , то этот вопрос для меня не праздный.

    AVC>>Плюс — у моей жены есть медицинское образование.
    Д>А это уже смахивает на паранойю.

    Что именно смахивает на паранойю? Дети? Медицинское образование? Образование в принципе?

    AVC>>"Тешь себя, тешь себя" (поглаживает) (с) "Ирония судьбы"

    Д>Не смешите мои тапочки. Эта тема уже десять раз тут обсасывалась. Ключевые слова для поиска — "мощность языка"

    Или "глюкавость".

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[18]: Нужна ли Оберон-ОС защита памяти?
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 15.02.05 15:18
    Оценка:
    Здравствуйте, AVC, Вы писали:

    Я тебя умоляю — выкидывай лишнее цитирование.
    ... << RSDN@Home 1.1.4 beta 4 rev. 326>>
    AVK Blog
    Re[19]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 15.02.05 15:26
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    OK.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[47]: Нужна ли Оберон-ОС защита памяти?
    От: Дарней Россия  
    Дата: 16.02.05 04:39
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>А также такие спорные вещи как "простота" и "корректность".


    Простота — она нередко хуже воровства. А "корректность" в случае ЯП... приведите ка определение этого термина, пожалуйста

    AVC>В свое время я писал приличное по размерам графическое приложение под Windows.

    AVC>Чтобы проверить, насколько я хорошо отделил представление от собственно модели, попросил товарища помочь с переносом под X-Windows (Linux).
    AVC>Весь перенос заключался в замене реализации нескольких графических классов и занял 2 часа.
    AVC>Странно, не правда ли?

    Единственный вариант, который здесь есть — это написание собственной кроссплатформенной оболочки, и написание программы поверх нее.
    Поэтому уточни еще — сколько времени ты затратил на разработку этой оболочки ДО этих двух часов?

    AVC>Что именно смахивает на паранойю? Дети? Медицинское образование? Образование в принципе?


    Утверждение, что некие большие компании намеренно портят людям здоровье. В нашей стране конечно всякое возможно, но не до такой степени. Пока что

    AVC>Или "глюкавость".


    Если ты говоришь про Оберон, то спорить не буду.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[48]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 16.02.05 09:05
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>А ты простестируй


    Может еще и рабочий код приведете?
    А то, знаете-ли, Ваш код:
    SomeObject *obj = new SomeObject();
    static int ref = (int)obj;

    в оберонах не компилируется.
    Re[49]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 16.02.05 09:08
    Оценка:
    Сергей Губанов пишет:

    > C>А ты простестируй

    > Может еще и рабочий код приведете?
    > А то, знаете-ли, Ваш код:
    >
    >SomeObject *obj = new SomeObject();
    >static int ref = (int)obj;
    >
    > в оберонах не компилируется.

    А с помощью System.Move разве передвинуть 4 байта из указателя в int нельзя?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 16.02.05 10:21
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>К тому же еще если для битовых операций использовать числа, то программа будет не переносимой между big и little endian архитектурами процессоров.


    Неправда. Логическая нумерация битов не зависит от xz-endian; операции "сдвиг вправо/влево" подразумевают логический порядок арабской записи чисел: старшие разряды слева, младшие справа.

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

    Ну а если бы некоторый процессор использовал не IEEE-шный формат float и double, тогда что, по-твоему, и от плавающей арифметики откажемся?
    Перекуём баги на фичи!
    Re[20]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 16.02.05 10:23
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

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

    К>>Как в языках со слабой типизацией абстрагируются от типа данных, так в Си (ещё не С++) — от размещения данных.
    К>>В обоих случаях — это паттерн "простота (хуже воровства)", для слабо типизированных языков — получается более простой транслятор, для Си — облегчённый рантайм.

    СГ>В Обероне указатели есть (POINTER TO), но адресов и адресной арифметики нет. И именно из-за отсутствия адресов механизм абстракции не очень выразительный. Странно...


    <>

    И к чему этот выстрел в воздух?..
    Перекуём баги на фичи!
    Re[20]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 16.02.05 11:42
    Оценка:
    Сергей Губанов wrote:

    > С другой стороны в оберонах есть элементарный тип "множество", которого нет в Си/Си++/Java/C#, а в языке Си даже нет булевского типа. А выразительность значит меньше. Опять странно...

    >
    > Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

    Не такой уж он элементарный. В С++ есть куча шаблонов множеств для разных сценариев использования: std::bitset, boost::dynamic_bitset, std::vector<bool>, std::set и до кучи std::multiset — множество с повторениями.

    > Как интересно в Си/Си++/Java/C# работают с битами? Наверное там битовые операции применяют прямо к числам?


    По всякому. Иногда действительно битовыми операциями с числами, иногда с bitset, иногда с bit fields.

    > Вот несчастные программисты, как они там мучаются — ведь в Си/Си++/Java/C# множество битов и числа — это одно и тоже, хотя спроси любого математика так он ответит, что число — это одна математическая абстракция (теория чисел), а множество — совсем другая (теория множеств).

    >
    >
    > VAR s1, s2, s3: SET;
    
    Эээ, а что, в Обероне множества не типизированы?
    
    >     n, m: INTEGER;
    > BEGIN
    >   s1 := {0,1,2,3}; (* Первые четыре бита = 1, остальные 32-4 = 28 битов равны 0 *)
    >   s2 := s1;
    >   n := 13;
    >   m := 2;
    >   INCL(s2, n); (* n-тый бит теперь равен 1 *)
    
    Эээ, а если написать INCL(s2, 4000000000), то будет поднят бит № четыре миллиарда?
    
    >   EXCL(s2, m); (* m-тый бит теперь равен 0 *)
    >   s3 := s1 + s2 + {25, 26}; (* Объединение трех множеств. В объединеном множестве присутсвуют все элементы присутсвующие во всех объединяемых множествах *)
    >   s3 := s1 * s2; (* Пересечение множеств - остаются только элементы присутсвующие и в первом и во втором множестве *)
    >   s3 := s1 - s2; (* Разность множеств. Из вычистаемого множества удаляются элементы присутсвующие в вычитаемом множестве *)
    >   s3 := s1 / s2; (* Симметричная разность множеств. Объединение разностей множеств s1 / s2 = (s1 - s2) + (s2 - s1) *)
    >   m := ORD(s3);  (* Sum i IN s3: 2^i *)
    >   s1 := BITS(n); (* {i | ODD(n DIV 2^i)} *)
    >
    Posted via RSDN NNTP Server 1.9
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 16.02.05 12:56
    Оценка:
    Кодт wrote:

    > СГ>Как интересно в Си/Си++/Java/C# работают с битами? Наверное там битовые операции применяют прямо к числам? Вот несчастные программисты, как они там мучаются — ведь в Си/Си++/Java/C# множество битов и числа — это одно и тоже, хотя спроси любого математика так он ответит, что число — это одна математическая абстракция (теория чисел), а множество — совсем другая (теория множеств).

    >
    > Вот ты для разнообразия и спроси математика, какими способами можно представить множества...
    > Навскидку:
    > — предикат как чёрный ящик
    > — предикат как формула
    > — булев вектор (элементы универсума пронумерованы)
    > — упорядоченная последовательность (над элементами определено отношение порядка)
    > — неупорядоченная последовательность (над элементами определено отношение эквивалентности)

    — еще порождающая функция — yield'ещая все элементы множества или выставляющая наружу итератор по элементам
    Posted via RSDN NNTP Server 1.9
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 14:48
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.

    К>К примеру, матрицы. Не просто "двумерный массив", а именно матрицы со всей их алгеброй. Почему в Обероне нет матричной алгебры?


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

    К>А между прочим, она уже давным-давно реализована на уровне языка: смотри APL, MatLab.

    К>Я даже не прошу тензорную алгебру, бог с ней, она не часто нужна, да и размерности там офигительные. Хотя в минимальном виде (аффиноры) можно было бы.
    К>А куда делись столь нужные 3D-моделистам кватернионы?
    К>И после этого ты ещё осмеливаешься хвалить Оберон?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 16.02.05 15:29
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Справедливости ради, матричная алгебра на Обероне реализуется проще, чем на Си++.

    AVC>Причина: отсутствие в Си++ многомерных гибких массивов.
    AVC>В Обероне даже не требуются классы (записи), достаточно массивов.
    AVC>Я и обратил впервые внимание на Оберон из-за того, что там легко было обобщить методы линейной алгебры для матриц разных размерностей.
    AVC>Потом уже стало "доходить", что разница между Обероном и Си++ глубже, чем наличие или отсутствие тех или иных фич. Тогда заинтересовался всерьез.

    В С++, благодаря шаблонам, есть возможность контролировать размеры матриц на стадии компиляции

    Кстати, я всё-таки не понял: ARRAY OF ARRAY (без фиксированного размера) — это прямоугольник или рваный край?
    Если рваный край, то просто массивов недостаточно, потребуется обвеска хотя бы в виде функций инициалазации. Как и в случае vector<vector<>>.
    А если прямоугольник — то действительно, раз — и готово!

    Но опять же, в С++ можно сделать код, эквивалентный Обероновскому.
    Введём только, с помощью шаблона, тип "двумерный массив".
    template<class T>
    class array2d
    {
    public:
      int xsize() const;
      int ysize() const;
    
      array2d(); // 1*1
      array2d(int x, int y);
      array2d(const array2d& src);
      array2d& operator=(const array2d& src);
    
      T& at(int x, int y);
      const T& at(int x, int y) const;
    };

    Минимально, этого достаточно. Дальше — вагон и маленькая тележка функций, таких же, как в Обероне.
    Перекуём баги на фичи!
    Re[23]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 15:51
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    AVC>>Справедливости ради, матричная алгебра на Обероне реализуется проще, чем на Си++.

    AVC>>Причина: отсутствие в Си++ многомерных гибких массивов.
    AVC>>В Обероне даже не требуются классы (записи), достаточно массивов.
    AVC>>Я и обратил впервые внимание на Оберон из-за того, что там легко было обобщить методы линейной алгебры для матриц разных размерностей.
    AVC>>Потом уже стало "доходить", что разница между Обероном и Си++ глубже, чем наличие или отсутствие тех или иных фич. Тогда заинтересовался всерьез.

    К>В С++, благодаря шаблонам, есть возможность контролировать размеры матриц на стадии компиляции


    Гм. Как бы это поделикатнее сказать...
    Мне даже интересно, а где этой возможности нет?
    Например:
    VAR a: ARRAY 10,10 OF REAL;
    И так в большинстве языков...

    К>Кстати, я всё-таки не понял: ARRAY OF ARRAY (без фиксированного размера) — это прямоугольник или рваный край?


    Прямоугольник.
    Кирпич.
    И т.д.

    К>Если рваный край, то просто массивов недостаточно, потребуется обвеска хотя бы в виде функций инициалазации. Как и в случае vector<vector<>>.

    К>А если прямоугольник — то действительно, раз — и готово!

    Прямоугольник.

    К>Но опять же, в С++ можно сделать код, эквивалентный Обероновскому.

    К>Введём только, с помощью шаблона, тип "двумерный массив".
    К>
    К>template<class T>
    К>class array2d
    К>{
    К>public:
    К>  int xsize() const;
    К>  int ysize() const;
    
    К>  array2d(); // 1*1
    К>  array2d(int x, int y);
    К>  array2d(const array2d& src);
    К>  array2d& operator=(const array2d& src);
    
    К>  T& at(int x, int y);
    К>  const T& at(int x, int y) const;
    К>};
    К>

    К>Минимально, этого достаточно. Дальше — вагон и маленькая тележка функций, таких же, как в Обероне.

    Конечно.
    Си++, как всегда, выгодно отличается от Оберона своей простотой.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 16:44
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Я имел в виду

    K>
    К>VAR a: ARRAY 3,5 OF REAL;
    К>    b: ARRAY 5,7 OF REAL;
    К>    c: ARRAY 4,7 OF REAL;
    К>    d: ARRAY 3,7 OF REAL;
    
    К>d := a*b;
    К>d := a*c; (* ошибка компиляции: несовместимые операнды *)
    К>c := a*b; (* ошибка компиляции: несовместимые результат и приёмник *)
    К>


    Это хорошо.
    А если я захочу передать такую матрицу в некую функцию в качестве параметра?

    AVC>>Конечно.

    AVC>>Си++, как всегда, выгодно отличается от Оберона своей простотой.
    К>Планида у него такая. Бедность встроенных типов компенсируется мощностью пользовательских.

    И простотой.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 16:52
    Оценка:
    Здравствуйте, Костя Ещенко, Вы писали:

    СГ> Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

    КЕ>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для разных сценариев использования: std::bitset, boost::dynamic_bitset, std::vector<bool>, std::set и до кучи std::multiset — множество с повторениями.

    Прослеживается очень интересный подход.
    Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.
    Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[23]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 17:18
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Прослеживается очень интересный подход.

    >> Когда надо проиллюстрировать величие Си++, он берется со всеми
    >> библиотеками, даже нестандартными (пока?), как boost.
    >> Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом"
    >> виде.
    C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то
    C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_.

    И в чем разница? Почему "эээ, нет"?

    C>Причем при использовании этих библиотек внешний вид кода получается еще

    C>и получше обероновского.

    Мягко говоря, сомнительно.
    Рассмотрим хотя бы учебный пример:
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
    А уж про сообщения об ошибках, которые "вываливают" большинство Си++ных компиляторов я вообще молчу.
    ИМХО, несколько комично торжественно праздновать "победу" всей мощи Си++ных библиотек над "голым" языком, компилятор которого умещается в 50K.
    Хотя, на самом деле это показывает реальную меру "мощи" Си++.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 16.02.05 17:36
    Оценка:
    AVC,

    > C> Причем при использовании этих библиотек внешний вид кода получается еще и получше обероновского.


    > Мягко говоря, сомнительно. Рассмотрим хотя бы учебный пример:

    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());


    Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?
    Posted via RSDN NNTP Server 2.0 alpha
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 16.02.05 20:19
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Прослеживается очень интересный подход.


    и заметим, нездоровый...

    AVC>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

    AVC>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

    Знаешь, почему? Потому что приверженцы Оберона всячески подчёркивают, что в самом языке достаточно фич, чтобы "было щастье". А избалованные библиотеками С++ники считают, что нет, не достаточно.
    Перекуём баги на фичи!
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 16.02.05 22:28
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    >> Мягко говоря, сомнительно. Рассмотрим хотя бы учебный пример:

    >>
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

    ПК>Интересно... А если исправить ошибки в этом коде, то как будет выглядеть эквивалентный код на Обероне?

    Опаньки! неужели сам...
    Павел, а где, собственно, ошибки?
    Вот беру исходник
    #include <list>
    
    using namespace std;
    
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());
    
    int main()
    {
        return 0;
    }
    и компилирую. Ошибок нет!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Костя Ещенко Россия  
    Дата: 16.02.05 23:38
    Оценка:
    Здравствуйте, AVC, Вы писали:

    СГ>> Кстати про множества, а почему элементарный тип bool в языки C++/Java/C# все-таки ввели, а элементарный тип "множество" проигнорировали?

    КЕ>>Не такой уж он элементарный. В С++ есть куча шаблонов множеств для разных сценариев использования: std::bitset, boost::dynamic_bitset, std::vector<bool>, std::set и до кучи std::multiset — множество с повторениями.

    AVC>Прослеживается очень интересный подход.

    AVC>Когда надо проиллюстрировать величие Си++, он берется со всеми библиотеками, даже нестандартными (пока?), как boost.

    Вообще-то это был ответ на вопрос Сергея, почему проигнорировали "элементарный" тип множество. Чем ответ не устраивает и что не так с библиотеками?
    Они же стандартные или типа того. Есть почти на каждом компиляторе. Их реализация не обязана находиться в исходных файлах, а может быть встроена в компилятор. С точки зрения Стандарта это стандартные типы/функции/шаблоны, почти как int.

    AVC>Когда надо проиллюстрировать ничтожество Оберона, он берется в "голом" виде.

    AVC>

    Я не иллюстрировал, оно само
    А что, в "одетом" виде у Оберона есть стандартные или нестандартные библиотеки, реализующие множества? И что, типизированные? На дженериках?
    На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.02.05 05:19
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Это хорошо.


    AVC>А если я захочу передать такую матрицу в некую функцию в качестве параметра?

    Вот как раз в С++ ты такую матрицу в функцию передашь легко. Там можно описывать фунции с весьма занятными ограничениями на принимаемые параметры. В частности, описываемое поведение достигается применением специальной версии оператора *, в которую принимаются исключительно матрицы подходящих размерностей.
    AVC>И простотой.
    Да, и простотой. Потому что в реальной жизни делается примерно так:
    typedef Matrix<3, 3, float> Matrix3d;
    typedef Matrix<3, 1, float> Vector3d;
    typedef Matrix<1, 3, float> CoVector3d;
    // определим скалярное произведение для удобства
    float operator * (Vector3d &a, Vector3d &b)
    {
      static const Matrix<1, 1, float> transposer = Matrix<1, 1, float>(1.0);
        return (a*transposer*b)[0][0]; // преобразует Vector3d в CoVector3d, чтобы можно было выполнить умножение
    }

    И все. Это делается в одном хидере, и все эти страшные наборы вложенных угловых скобок никто не видит.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 10:48
    Оценка:
    Здравствуйте, Павел Кузнецов, Вы писали:

    ПК>Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):

    ПК>
    ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );
    ПК>


    ПК>

    ПК>(*) В сознательном вредительстве его можно уличить, т.к. объявления dataFile он не предоставил

    Предполагаю...
    1) Сперва избавимся от адресной арифметики, скрытой в концепции итераторов.
    Перейдём к эквивалентной концепции — диапазонов и генераторов.
    Генератор — это аналог output iterator.
    // над генератором определены 2 функции: read и end
    
    template<class G>
    typename generator_traits<G>::type
    read(G gen);
    
    template<class G>
    bool
    ends(G gen);
    
    // конкретно, с файлом:
    template<class T>
    struct istream_generator
    {
      istream* istr;
    };
    template<class T>
    T read(istream_generator<T> gen)
    {
      T var;
      gen.istr->read(var);
      return var;
    }
    template<class T>
    T ends(istream_generator<T> gen)
    {
      return gen.istr->eof();
    }
    
    // конструктор списка
    
    template<class G>
    list<T>::list(G gen)
    {
      while(!ends(gen)) push_back(read(gen));
    }

    2) Заодно, по мере сил, избавимся от шаблонов, — только generics.
    template<class T>
    struct IGenerator
    {
      virtual T read() = 0;
      virtual bool ends() const = 0;
    };
    
    template<class T>
    struct istream_generator : IGenerator<T>
    {
      istream* istr;
      T read() { T var; istr->read(var); return var; }
      bool ends() const { return istr->eof(); }
    };
    
    list<T>::list(IGenerator<T>* gen)
    {
      while(!gen->ends()) push_back(gen->read());
    }

    3) А если и generics недоступны — нарожаем конкретных интерфейсов и классов.
    Перекуём баги на фичи!
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 10:54
    Оценка:
    Здравствуйте, Kh_Oleg, Вы писали:

    K_O>
    list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

    ПК>>В данном случае мы имеем дело с одной из неприятных особенностей синтаксиса C++: вопреки очевидному желанию программиста объявить список, проинициализированный парой итераторов, вместо этого мы видим объявление функции data, возвращающей list<int>.

    K_O>Шикарнейший язык!


    K_O>
    ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );

    K_O>Читал, много думал...
    K_O>Почему взятие итераторов в скобки меняет смысл объявления?

    Потому что есть правило "если нечто выглядит как объявление функции, это и есть объявление функции".
    В данном случае,
    T name(U (u), V (v)); // где T, U, V - типы; name, u, v - идентификаторы

    U (u) можно трактовать как элемент объявления аргумента. Был бы там вместо u литерал или выражение — всё стало бы однозначно конструктором временного объекта типа U. А так — неоднозначность.
    А вот (U(u)) уже невозможно трактовать как объявление аргумента.
    Перекуём баги на фичи!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 12:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    AVC>>И простотой.

    S>Да, и простотой. Потому что в реальной жизни делается примерно так:
    S>
    S>typedef Matrix<3, 3, float> Matrix3d;
    S>typedef Matrix<3, 1, float> Vector3d;
    S>typedef Matrix<1, 3, float> CoVector3d;
    S>// определим скалярное произведение для удобства
    S>float operator * (Vector3d &a, Vector3d &b)
    S>{
    S>  static const Matrix<1, 1, float> transposer = Matrix<1, 1, float>(1.0);
    S>    return (a*transposer*b)[0][0]; // преобразует Vector3d в CoVector3d, чтобы можно было выполнить умножение
    S>}
    S>

    S>И все. Это делается в одном хидере, и все эти страшные наборы вложенных угловых скобок никто не видит.

    Ага-ага, начинаю понимать.
    А для векторов длины 4 мы напишем еще один оператор:
    float operator * (Vector4d &a, Vector4d &b)
    и т.д.
    И так для каждой новой размерности.
    Вот здорово! Как просто-то!
    Вот только я опять не понял:

    "А если я захочу передать такую матрицу в некую функцию в качестве параметра?"

    Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: GlebZ Россия  
    Дата: 17.02.05 13:05
    Оценка:
    Здравствуйте, Kh_Oleg, Вы писали:

    K_O>Теперь понятно, спасибо.

    K_O>Была бы возможность, я бы сейчас поставил языку С++ много минусов.
    Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно.

    С уважением, Gleb.
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 17.02.05 13:08
    Оценка:
    AVC пишет:

    > S>И все. Это делается в одном хидере, и все эти страшные наборы

    > вложенных угловых скобок никто не видит.
    > Ага-ага, начинаю понимать.
    > А для векторов длины 4 мы напишем еще один оператор:

    Не длины, а _размерности_. Работа с векторами разной размерности бывает
    нужна очень редко (а вот 2,3,4-мерные вектора нужны часто). Кстати, при
    желании можно с темплейтами сделать и вектора произвольной размерности.

    >float operator * (Vector4d &a, Vector4d &b)

    >
    > и т.д.
    > И так для каждой новой размерности.
    > Вот здорово! Как просто-то!
    > Вот только я опять не понял:
    > "А если я захочу передать такую матрицу в некую функцию в качестве
    > параметра?"
    > Намек: функция уже написана, откомпилирована и покоится себе в
    > какой-нибудь DLL.

    А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я
    вот, например, спокойно передаю std::map'ы нехилых по сложности
    темплейтных объектов между DLLками. И ничего, все работает.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 13:12
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Ага-ага, начинаю понимать.

    AVC>А для векторов длины 4 мы напишем еще один оператор:
    float operator * (Vector4d &a, Vector4d &b)
    и т.д.

    AVC>И так для каждой новой размерности.
    AVC>Вот здорово! Как просто-то!

    Неа! Мы напишем шаблон и не будем забивать голову посторонними предметами.

    AVC>Вот только я опять не понял:

    "А если я захочу передать такую матрицу в некую функцию в качестве параметра?"

    AVC>Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.

    Ответный намёк: в твоей программе используются 4 вида матриц: плотные, разреженные, треугольные и диагональные. А алгоритм откомпилирован и покоится себе в каком-то модуле.
    Что ты будешь делать?

    — копи-пастом нарожаешь алгоритмы для всех видов
    — или же сделаешь интерфейс матрицы (при этом, вот досада, все эти встроенные ARRAY OF ARRAY уже наружу торчать не будут) и пусть алгоритм работает через интерфейс
    Перекуём баги на фичи!
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 13:14
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я

    C>вот, например, спокойно передаю std::map'ы нехилых по сложности
    C>темплейтных объектов между DLLками. И ничего, все работает.

    До тех пор, пока не будешь иметь дело с Dinkumware STL
    Перекуём баги на фичи!
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 17.02.05 13:17
    Оценка:
    Кодт пишет:

    > C>А какие проблемы? Инстанцированные темплейты — вполне обычные классы. Я

    > C>вот, например, спокойно передаю std::map'ы нехилых по сложности
    > C>темплейтных объектов между DLLками. И ничего, все работает.
    > До тех пор, пока не будешь иметь дело с Dinkumware STL

    Поэтому STLPort у меня рядышком в проекте лежит

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.02.05 13:21
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Ага-ага, начинаю понимать.

    AVC>А для векторов длины 4 мы напишем еще один оператор:
    float operator * (Vector4d &a, Vector4d &b)
    и т.д.

    AVC>И так для каждой новой размерности.
    Ну зачем. Если ты настаиваешь, я могу тебе написать оператор скалярного умножения для любых векторов.
    AVC>Вот здорово! Как просто-то!
    Именно. На обероне-то вообще ты это никак не опишешь. Только в рантайме будешь трапы трапать.
    AVC>Вот только я опять не понял:

    "А если я захочу передать такую матрицу в некую функцию в качестве параметра?"

    AVC>Намек: функция уже написана, откомпилирована и покоится себе в какой-нибудь DLL.
    Опять от одной коровы двенадцать поросят? "Как мне передать int в функцию, которая принимает string?"

    Если хочется передавать матрицу через границу compile unit, то можно отнаследовать ее от соответствующего интерфейса. Таким образом, статический контроль размерностей будет жить там, где есть эта информация, а где нету — там будет жить динамический контроль.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: Kh_Oleg  
    Дата: 17.02.05 13:23
    Оценка:
    Здравствуйте, GlebZ, Вы писали:

    K_O>>Теперь понятно, спасибо.

    K_O>>Была бы возможность, я бы сейчас поставил языку С++ много минусов.
    GZ>Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно.
    Ну вот встретилась же.
    Такая конструкция может возникнуть при объявлении переменной любого типа, у которого в конструктор можно передать параметры.

    На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции".
    Но вот в случае с глобальными переменными ситуация меняется.
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: GlebZ Россия  
    Дата: 17.02.05 13:46
    Оценка:
    Здравствуйте, Kh_Oleg, Вы писали:

    K_O>Здравствуйте, GlebZ, Вы писали:


    K_O>>>Теперь понятно, спасибо.

    K_O>>>Была бы возможность, я бы сейчас поставил языку С++ много минусов.
    GZ>>Ну вот, еще один человек не любит С++. А ведь с такой конструкцие встретиться практически невозможно.
    K_O>Ну вот встретилась же.
    K_O>Такая конструкция может возникнуть при объявлении переменной любого типа, у которого в конструктор можно передать параметры.
    И у которой параметры могут интерпретироваться как типы. А вот такое делать уже значительно сложнее.

    K_O>На самом деле, обычно (по крайней мере, у меня), таких ситуаций не возникает, потому что 99% переменных объявлены либо в классе, либо в методе, где объявление функции недопустимо, а потому это и "не выглядит, как объявление функции".

    K_O>Но вот в случае с глобальными переменными ситуация меняется.
    Почти нет. Хотя действительно глобальные переменные практически не используются. Разве что статики.

    С уважением, Gleb.
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 14:54
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...


    Гм. А разные версии шаблонных библиотек разве не именно так пекут?
    Многопоточность встроена в Активный Оберон (там, кстати, на уровне ОС еще и многопроцессорность).
    Я же держусь поближе к стандартному Оберону-2, и рассматриваю его возможности в качестве основного языка для встроенных систем определенного масштаба.
    А матричную алгебру я не предлагал встроить в язык, а имел в виду обычный обероновский модуль. (Если используется динамический загрузчик, то это аналог DLL, но с полным контролем типов.)

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[23]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 15:02
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> MIN(SET) = 0

    >> MAX(SET) = 31
    >> (MIN, MAX — стандартные процедуры-функции)

    C>Удивительно болшое множество....


    Даже в Turbo Pascal 3 было 256...
    Перекуём баги на фичи!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 17.02.05 15:02
    Оценка:
    AVC пишет:

    > К>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там

    > матричную алгебру или ещё какую фичу...
    > Гм. А разные версии шаблонных библиотек разве не именно так пекут?
    > Многопоточность встроена в Активный Оберон (там, кстати, на уровне ОС
    > еще и многопроцессорность).
    > Я же держусь поближе к стандартному Оберону-2, и рассматриваю его
    > возможности в качестве основного языка для встроенных систем
    > определенного масштаба.
    > А матричную алгебру я не предлагал встроить в язык, а имел в виду
    > обычный обероновский модуль. (Если используется динамический
    > загрузчик, то это аналог DLL, но с полным контролем типов.)

    Обероновской библиотеке придется экспортировать полиморфные интерфейсы,
    такого статического контроля как в С++ — не будет.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 15:13
    Оценка:
    Здравствуйте, AVC, Вы писали:

    К>>Вот и пекут обероны, как блины. Здесь многопоточность встроим, там матричную алгебру или ещё какую фичу...


    AVC>Гм. А разные версии шаблонных библиотек разве не именно так пекут?


    На STL есть спецификация в Стандарте. В пределах спецификации обеспечивается взаимозаменяемость версий.

    А другие библиотеки — это не "разные версии", а всё же разные библиотеки. Которые можно использовать одновременно.
    Перекуём баги на фичи!
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 15:15
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>AVC пишет:


    >> C>Эээ, нет. Когда пытаются продемонстировать суперфичи _языка_ Оберон, то

    >> C>С++-ники показывают еще более мощные аналогичные фичи _библиотек_.
    >> И в чем разница? Почему "эээ, нет"?
    C>Сравни сложность изменения/замены бибилиотеки (ну захотелось мне другой
    C>способ представления матриц использовать) и сложность модификации языка.

    Во-первых, так и не понял в чем разница. Я сказал, что берутся библиотеки Си++ против "голого" языка Оберон. (Я считаю, что это абсурдное сравнение.) Вы повторяете то же самое, но как будто со мной спорите. Мне это непонятно.
    У меня и раньше создавалось впечатление, что Вы полагаете, что библиотеки возможны только в Си++. Но это же явное заблуждение.
    А теперь сравним сложность замены библиотек в Си++ (особенно если Вы используете библиотеки шаблонов) и Обероне.
    В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект.
    Так что же сложнее?

    C>Вполне нормальные сообщения. Правда длииииинные.

    И не читwrertytfjygh::<jhi>ljhljkhlkjgабельные.

    >> Хотя, на самом деле это показывает реальную меру "мощи" Си++.


    C>Это мера _практичности_ языка С++. При его разработке не старались

    C>добавить языковую поддержку как можно большего числа фич (типа
    C>множеств), а пытались дать достаточно средств, что можно было комфортно
    C>реализовать как максимальное число фич.

    Насчет комфортности — я уже приводил примеры "комфортных" текстов на Си++.
    Честные книги о программировании на плюсах полны текстов вроде:

    Ты туда не ходи, ты сюда ходи. Там снег башка попадет...

    (c) "Джентльмены удачи"

    C>А вот Вирт решил: "Так, нам нужен GC, множества и многомерные массивы

    C>непосредственно в языке. Остальное нам в языке не нужно.".

    И ведь этого хватает!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 15:23
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>А теперь сравним сложность замены библиотек в Си++ (особенно если Вы используете библиотеки шаблонов) и Обероне.

    AVC>В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект.
    AVC>Так что же сложнее?

    Передёргивание.

    Если интерфейсная часть не поменялась, достаточно заменить .lib / .out / .so / .dll или как там называются загружаемые модули в конкретной системе.

    А если в обероновском модуле расковырять интерфейсную часть, то тоже всё придётся пересобирать.
    Перекуём баги на фичи!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 15:30
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    AVC>>В Си++ Вам придется перекомпилировать все проекты (в мире ), использующие данную библиотеку. О скорости компиляции (с текстовыми хэдерами) и линковки множества файлов можно даже не говорить. А в Обероне Вы просто не заметите замены библиотеки. Вам не придется перекомпилировать проект.

    AVC>>Так что же сложнее?
    К>Передёргивание.

    В чем именно?

    К>Если интерфейсная часть не поменялась, достаточно заменить .lib / .out / .so / .dll или как там называются загружаемые модули в конкретной системе.


    И в случае замены шаблона?

    К>А если в обероновском модуле расковырять интерфейсную часть, то тоже всё придётся пересобирать.


    Так ведь Cyberax говорил не о замене интерфейса библиотеки, а о замене реализации.
    Придираетесь, батенька!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 17.02.05 15:39
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Так ведь Cyberax говорил не о замене интерфейса библиотеки, а о замене реализации.

    AVC>Придираетесь, батенька!

    Прекрасно. Берём любой обероновский модуль, пишем на С++ эквивалентную систему типов, которая встречается в интерфейсе (те же динамические массивы). Дальше, поскольку шаблонов в интерфейсе нет, вытаскиваем реализацию в отдельный .cpp.
    Потом вносим изменения в обероновский и в С++ный код. И обнаруживаем, что головная боль для клиента — практически одинаковая (заменить объектный файл).

    С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.
    Перекуём баги на фичи!
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 17.02.05 15:52
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Прекрасно. Берём любой обероновский модуль, пишем на С++ эквивалентную систему типов, которая встречается в интерфейсе (те же динамические массивы).

    K>Дальше, поскольку шаблонов в интерфейсе нет, вытаскиваем реализацию в отдельный .cpp.

    Что я и говорил : шаблоны плохо сочетаются с динамической линковкой.

    К>Потом вносим изменения в обероновский и в С++ный код. И обнаруживаем, что головная боль для клиента — практически одинаковая (заменить объектный файл).


    Если речь идет о DLL, то да.
    Хотя создание DLL на Си++ требует дополнительных пырханий и модификации исходника (__dllspec и т.д.).

    К>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.


    Так ведь и платим! Вон уже сколько гигабайт требуется на винте.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Павел Кузнецов  
    Дата: 17.02.05 16:23
    Оценка:
    AVC,

    > ПК> Итак, мне, все-таки, действительно, интересно, как бы выглядел на Обероне код, подобный следующему (считаем, что соответствующий контекст предоставлен, в т.ч. нужные #includes, определение dataFile и т.п.):

    > ПК>
    > ПК>list<int> data( (istream_iterator<int>(dataFile)),  (istream_iterator<int>()) );
    > ПК>

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

    Ессно. Я просто думал, что там уже есть какой-то готовый аналог.
    Posted via RSDN NNTP Server 2.0 alpha
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 08:09
    Оценка:
    Здравствуйте, AVC, Вы писали:

    К>>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.


    AVC>Так ведь и платим! Вон уже сколько гигабайт требуется на винте.


    Знаешь, вот если я не использую буст в своём проекте, то обновление буста никак не отразится на скорости компиляции. Да и вообще ставить его не придётся.
    Не хочешь, не плати.
    Перекуём баги на фичи!
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 18.02.05 10:47
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>Здравствуйте, Cyberax, Вы писали:


    >>> MIN(SET) = 0

    >>> MAX(SET) = 31
    >>> (MIN, MAX — стандартные процедуры-функции)

    C>>Удивительно болшое множество....


    К>Даже в Turbo Pascal 3 было 256...


    Зато работает быстрее, т.к. 256 битов в одном регистре не убираются, а 32 бита убираются.
    Re[21]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 18.02.05 11:01
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.


    Ответ прост:
  • Множество (SET) — есть скалярный тип, такой же элементарный как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе скалярный, но используемый как контейнер.
  • Комплексные числа, кватернионы, матрицы, векторы и т. п. — компонентные объекты (составные) не скалярные.
  • Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Sergey Россия  
    Дата: 18.02.05 11:05
    Оценка:
    Hello, Сергей!
    You wrote on Fri, 18 Feb 2005 11:01:50 GMT:

    СГ> Ответ прост:

    СГ>
  • Множество (SET) — есть скалярный тип, такой же элементарный
    СГ> как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква
    СГ> (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним
    СГ> можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или
    СГ> p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе
    СГ> скалярный, но используемый как контейнер.
  • Комплексные числа,
    СГ> кватернионы, матрицы, векторы и т. п. — компонентные объекты
    СГ> (составные) не скалярные.

    А мне, как программисту, какая, нафиг разница, составные там объекты или
    цельнокованные? Собственно, составные даже удобнее — от них наследоваться
    можно.

    With best regards, Sergey.
    Posted via RSDN NNTP Server 1.9
  • Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
    Re[22]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 11:29
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Кодт, Вы писали:


    К>>А теперь вопрос, почему нужно тащить в язык такую абстракцию, как множества (пусть даже в каком-то фиксированном виде), но забить на другие абстракции.


    СГ>Ответ прост:

    СГ>
  • Множество (SET) — есть скалярный тип, такой же элементарный как 1) целое число (INTEGER), 2) действительное число (REAL), 3) буква (CHAR), 4) логическое значение (BOOLEAN), 5,6) если угодно, то к ним можно отнести даже обобщенный указательный тип (POINTER TO, p = NIL или p # NIL), а также обобщенный массивовый тип ARRAY OF — сам по себе скалярный, но используемый как контейнер.
    СГ>
  • Комплексные числа, кватернионы, матрицы, векторы и т. п. — компонентные объекты (составные) не скалярные.

    Множество как математическая абстракция — это не скалярный тип.
    SET — это очень узкий случай множества {0..31}, сделанный элементарным.
    Точно так же, целые числа без ограничений разрядности могут быть (LISP, Python), а могут не быть (Smalltalk, C++) элементарным типом. А целые числа небольшой разрядности (приемлемой для большинства платформ — скажем, 32 или 64 бита) — элементарный тип.
    Комплексные числа — могут быть элементарным типом (Fortran, MatLab), а могут реализовываться как составные (C++).
    Кватернионы и 3-мерные аффиноры тоже могли бы быть элементарным типом, если бы встречались достаточно часто.

    P.S.
    Понимая глубинную суть языка (С++, Оберон и т.д.), не надо сужать горизонт только до него одного.
    Самое интересное начинается на границе и за границей познанного
  • Перекуём баги на фичи!
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 18.02.05 11:39
    Оценка:
    Сергей Губанов пишет:

    > C>Удивительно болшое множество....

    > Ни что мешает сделать так:
    >
    >TYPE
    > BigSet = ARRAY 1000000 OF SET;
    >
    А чем это лучше
    int arr[100000];
    ? И как будут выглядеть
    операции над таким составным множеством?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[63]: Нужна ли Оберон-ОС защита памяти?
    От: RailRoadMan  
    Дата: 18.02.05 12:38
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>То есть, если пользователь Вася загрузит модуль "Photoshop", то

    C>пользователь Петя уже не сможет его загрузить?

    C>Или Оберон — исключительно однопользовательский?


    http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm
    http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

    Ссылки приводил Сергей Губанов
    Там явно написано, что ОДНОПОЛЬЗОВАТЕЛЬСКАЯ
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 15:23
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Удивительно болшое множество....

    СГ> Ни что мешает сделать так:
    >>
    >>TYPE
    >> BigSet = ARRAY 1000000 OF SET;
    >>
    C>А чем это лучше
    int arr[100000];
    ? И как будут выглядеть

    C>операции над таким составным множеством?

    Примерно так:
    DEFINITION BitSets;
    
    TYPE
      BitSet* = RECORD 
        size-: INTEGER; (** число элементов в битовом множестве *)
        PROCEDURE (VAR set: BitSet) Init*(size: INTEGER);
        PROCEDURE (VAR set: BitSet) Incl*(bit: INTEGER);
        PROCEDURE (VAR set: BitSet) Excl*(bit: INTEGER);
      END;
    
    END BitSets.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[31]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 15:34
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>>>С++, помимо этого, предоставляет дополнительные возможности, за которые (если они востребованы) нужно дополнительно платить.

    AVC>>Так ведь и платим! Вон уже сколько гигабайт требуется на винте.
    К>Знаешь, вот если я не использую буст в своём проекте, то обновление буста никак не отразится на скорости компиляции. Да и вообще ставить его не придётся.
    К>Не хочешь, не плати.

    Я (как программист) могу и не использовать boost.
    Я его и не использую. Не по каким-то принципиальным соображениям (например, boost::shared_ptr<T> я, в отстутствие GC, не прочь использовать), а просто нет необходимости. Это отдельный пункт — почему в таких важных супербиблиотеках нет большой практической необходимости?
    Но (как пользователь) замечу, что многие программы слишком велики по размерам, неадекватно их функциональности. А раз так, то мне требуется новый большой "винт". Т.е. я все-таки плачу (как пользователь), за некоторые технологии создания ПО.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 15:40
    Оценка:
    Здравствуйте, AVC, Вы писали:

    C>>А чем это лучше
    int arr[100000];
    ? И как будут выглядеть

    C>>операции над таким составным множеством?

    AVC>Примерно так:
    DEFINITION BitSets;
    
    AVC>TYPE
    AVC>  BitSet* = RECORD 
    AVC>    size-: INTEGER; (** число элементов в битовом множестве *)
    AVC>    PROCEDURE (VAR set: BitSet) Init*(size: INTEGER);
    AVC>    PROCEDURE (VAR set: BitSet) Incl*(bit: INTEGER);
    AVC>    PROCEDURE (VAR set: BitSet) Excl*(bit: INTEGER);
    AVC>  END;
    
    AVC>END BitSets.


    То есть, мы перестаём мучаться и извращаться с базовыми типами, и делаем нормальный класс с нормальными методами.
    ООП рулит

    Тут я хочу заметить некую фишку:

    — процедурное программирование — создаём операции над голыми типами (элементарными или составными); применяя разрешённый набор операций, мы сохраняем целостность модели; но помимо разрешённых (введённых нами + некое подмножество присущих языку и рантайму) можно по глупому или злому умыслу применять и другие.

    — ООП — операции суть неотъемлимые свойства объектов; за счёт инкапсуляции невозможно получить злодейский доступ к голым данным.

    Указатели и массивы — это голые типы; возможность misuse/abuse их необычайна (особенно в С++, где есть прямой доступ к памяти; хотя и в Обероне, и в Васике можно разломать программу на логическом уровне).

    Такова цена, которую программист платит за язык, совмещающий несколько парадигм одновременно (процедурное + ООП).
    Перекуём баги на фичи!
    Re[24]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 15:41
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Ни что мешает сделать так:

    СГ>
    СГ>TYPE
    СГ>  BigSet = ARRAY 1000000 OF SET;
    СГ>

    Только еще бы "завернуть" в класс.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 15:57
    Оценка:
    Здравствуйте, Кодт, Вы писали:

    К>- процедурное программирование — создаём операции над голыми типами (элементарными или составными); применяя разрешённый набор операций, мы сохраняем целостность модели; но помимо разрешённых (введённых нами + некое подмножество присущих языку и рантайму) можно по глупому или злому умыслу применять и другие.

    К>- ООП — операции суть неотъемлимые свойства объектов; за счёт инкапсуляции невозможно получить злодейский доступ к голым данным.

    Полностью согласен.
    Хотя, наверное, здесь каждый согласится.
    Я так и рассматриваю класс как способ реализовать АТД, а АТД как некую математическую модель.
    В полном соответствии с учебником Ахо, Хопкрофта и Ульмана.
    Строить программы таким способом — кайф!
    Но вот беда с языками. У одного одни недостатки, у второго — другие.

    К>Указатели и массивы — это голые типы; возможность misuse/abuse их необычайна (особенно в С++, где есть прямой доступ к памяти; хотя и в Обероне, и в Васике можно разломать программу на логическом уровне).


    Увы...

    К>Такова цена, которую программист платит за язык, совмещающий несколько парадигм одновременно (процедурное + ООП).


    Следует ли это понимать как апологию Смоллтока?

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[32]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 18.02.05 15:59
    Оценка:
    AVC пишет:

    > Я (как программист) могу и не использовать boost.

    > Я его и не использую. Не по каким-то принципиальным соображениям
    > (например, boost::shared_ptr<T> я, в отстутствие GC, не прочь
    > использовать), а просто нет необходимости.

    Это только кажется.

    > Это отдельный пункт — почему в таких важных супербиблиотеках нет

    > большой практической необходимости?

    Speak for yourself... У меня практическая необходимость уже где для 40%
    буста

    > Но (как пользователь) замечу, что многие программы слишком велики по

    > размерам, неадекватно их функциональности. А раз так, то мне требуется
    > новый большой "винт". Т.е. я все-таки плач*у* (как пользователь), за
    > некоторые технологии создания ПО.

    А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место
    на диске.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[25]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 18.02.05 16:10
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Здравствуйте, Сергей Губанов, Вы писали:


    СГ>>Ни что мешает сделать так:

    СГ>>
    СГ>>TYPE
    СГ>>  BigSet = ARRAY 1000000 OF SET;
    СГ>>

    AVC>Только еще бы "завернуть" в класс.

    Можно, но надо-ли?
    PROCEDURE Incl(VAR s: ARRAY OF SET; Element: INTEGER);
    PROCEDURE Excl(VAR s: ARRAY OF SET; Element: INTEGER);
    
    PROCEDURE Included(VAR s: ARRAY OF SET; Element: INTEGER): BOOLEAN;
    
    PROCEDURE Union(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    PROCEDURE Difference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    PROCEDURE Intersection(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    PROCEDURE SymmetricDifference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Кодт Россия  
    Дата: 18.02.05 16:17
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>И чем это отличается от std::set, кроме отсутствия поддержки стандартных

    C>алгоритмов, итераторов, и удобного доступа?

    Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём библиотеки, эквивалентный STL?
    Перекуём баги на фичи!
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 18.02.05 16:22
    Оценка:
    Кодт пишет:

    > C>И чем это отличается от std::set, кроме отсутствия поддержки

    > стандартных
    > C>алгоритмов, итераторов, и удобного доступа?
    > Ну ты прямо хочешь, чтобы AVC тебе за полчаса нарожал весь объём
    > библиотеки, эквивалентный STL?

    Я бы не отказался и от "пошел ты на http://www...."

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 16:28
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Я бы не отказался и от "пошел ты на http://www...."


    Ну, уговорил...

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 16:41
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    AVC>>Только еще бы "завернуть" в класс.

    СГ>Можно, но надо-ли?
    СГ>
    СГ>PROCEDURE Incl(VAR s: ARRAY OF SET; Element: INTEGER);
    СГ>PROCEDURE Excl(VAR s: ARRAY OF SET; Element: INTEGER);
    
    СГ>PROCEDURE Included(VAR s: ARRAY OF SET; Element: INTEGER): BOOLEAN;
    
    СГ>PROCEDURE Union(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    СГ>PROCEDURE Difference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    СГ>PROCEDURE Intersection(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    СГ>PROCEDURE SymmetricDifference(IN s1, s2: ARRAY OF SET; OUT s3: ARRAY OF SET);
    СГ>


    Думаю, что надо (в общем случае).
    Вот какая проблема приходит в голову первой.
    Операции Union, Difference, Intersection и SymmetricDifference принимают в качестве аргументов открытые массивы.
    Следовательно, размерности входных параметров s1 и s2 могут не совпадать.
    Какой размерности должен быть выходной массив s3?
    Здесь можно принять некое соглашение. Например, для операции Union размерность выходного массива совпадает с размерностью наибольшего входного, а для операции Intersection — наименьшего.
    Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо. Здесь бы взять и удлинить выходной массив. Но для OUT s3: ARRAY OF SET это невозможно. Требуется как минимум указатель. А еще лучше — класс (= обероновская запись), позволяющий скрыть все детали и поступать гибко.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[33]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 17:22
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Это отдельный пункт — почему в таких важных супербиблиотеках нет

    >> большой практической необходимости?
    C>Speak for yourself... У меня практическая необходимость уже где для 40%
    C>буста

    Это уже зависимость.

    C>А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место

    C>на диске.

    Обероновское ПО как раз очень компактно.
    Так как исключается дублирование кода.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[34]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 18.02.05 17:31
    Оценка:
    AVC пишет:

    > C>А причем здесь буст? Тот же новый XDS будет ничуть ни хуже жрать место

    > C>на диске.
    > Обероновское ПО как раз очень компактно.
    > Так как исключается дублирование кода.

    Ну так надо поступать по образу и подобию libxml — ядро на С с
    биндингами во все возможные языки. И всего 1 dll'ка на диске.

    Ну и COM-объекты еще есть...

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 18.02.05 17:41
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>И чем это отличается от std::set, кроме отсутствия поддержки стандартных

    C>алгоритмов, итераторов, и удобного доступа?

    Нет, ну ей Богу, такое чувство, что Си++ у Вас — единственный язык.
    На всякий случай, сообщаю, что во многих языках есть классы.
    При этом языки различаются способами, как реализуются в них классы (и не только).
    Что касается сочетаемости std::set с алгоритмами и итераторами, то она зависит от того, как спроектирована библиотека в целом.
    Я же привел в качестве примера (как можно реализовать BitSet в виде класса) совсем простой класс. Этого вполне достаточно, чтобы проиллюстрировать ту мысль, но не более того.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: Cyberax Марс  
    Дата: 19.02.05 04:39
    Оценка:
    AVC пишет:

    > C>И чем это отличается от std::set, кроме отсутствия поддержки

    > стандартных
    > C>алгоритмов, итераторов, и удобного доступа?
    > Нет, ну ей Богу, такое чувство, что Си++ у Вас — единственный язык.

    Нет, у меня еще есть Java, C# и даже VBA.

    > На всякий случай, сообщаю, что *во многих* языках есть классы.

    > При этом языки различаются способами, *как* реализуются в них классы
    > (и не только).

    Я не спорю, коллекции можно реализовать вполне нормально (java.util.* —
    этому пример), но при этом потеряем статическую типизацию. И что самое
    важное, все дополнительные возможности языка Oberon так же пойдут лесом.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[29]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 21.02.05 11:50
    Оценка:
    Здравствуйте, Трурль, Вы писали:

    Т>А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?


    Т>
    Т>TYPE 
    Т>  Ptr(A) = POINTER TO A;
    Т>  List(A) = Ptr(ListDesc(A));
    Т>  ListDesc(A) = RECORD elem: Ptr(A); next: List(A) END;
    Т>


    Увы, пока не читал.
    Но теперь я знаю об этой статье и сегодня же прочту (уже скачал). Спасибо!
    Ясно было, что отсутствие в Обероне такой важной фичи не могло остаться без внимания.
    Я предполагал, что этот вопрос как-то уже решался, но не знал кем, где и когда.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 21.02.05 12:10
    Оценка:
    Здравствуйте, AVC, Вы писали:

    Обрадованный сообщением о применимости обобщенных типов к Оберону, нашел еще один пример (из инфы о компиляторе oo2c):
    http://cvs.sourceforge.net/viewcvs.py/*checkout*/ooc/ooc2/doc/from-v1-to-v2/oo2c-v2.html?rev=1.2#SEC19

    A parametric type can be seen as a type definition with a certain degree of freedom. The freedom comes in form of type parameters acting as placeholders for type arguments that are provided when the parametric type is used in a particular context. There are two restrictions on type parameters and type arguments: the parameter must be based on a record pointer, and the argument must be an extension of the parameter's base type.

    Take for example the type `ArrayList'. The element type of the list can be any type derived from `Object', like `MyElementType', which is provided when creating an `ArrayList' variable:

    TYPE
    ArrayList*(E: Object.Object) = POINTER TO ArrayListDesc(E);
    ArrayListDesc*(E: Object.Object) = RECORD
    ...
    END;
    ...
    VAR myList: ArrayList(MyElementType);


    The compiler statically detects any uses of `myList' or of its methods that are incompatible with the declared element type `MyElementType'.

    Практически один в один! Я и раньше предполагал, что иногда занимаюсь изобретением велосипедов.
    Но уже радует, что не вечных двигателей!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: Спасибо за информацию!
    От: AVC Россия  
    Дата: 21.02.05 13:40
    Оценка:
    AVC>Здравствуйте, Трурль, Вы писали:

    Т>>А Вы не читали Paul Roe and Clemens Szyperski "Lightweight Parametric Polymorphism for Oberon"?


    Прочитал.
    Extended Oberon — именно, то я хотел предложить. (Только у меня это были непроработанные мысли.)
    Достигнуты именно те цели, к которым я хотел приплыть:
    — нет никакой дополнительной нагрузки на рантайм;
    — используется единственный обобщенный код, который может быть представлен в объектном коде (например, в виде DLL).
    И т.д.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[27]: Нужна ли Оберон-ОС защита памяти?
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 21.02.05 13:41
    Оценка:
    Здравствуйте, AVC, Вы писали:

    AVC>Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо.


    Будет System trap — precondition failed.

    Впрочем, я с Вами согласен. Поверх этих процедур можно навесить ООП.
    Re[28]: Нужна ли Оберон-ОС защита памяти?
    От: AVC Россия  
    Дата: 21.02.05 14:13
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    AVC>>Но может оказаться так, что размерность s3 не совпадает с требуемой. Чтобы совсем все было плохо, пусть она будет меньше, чем надо.

    СГ>Будет System trap — precondition failed.
    СГ>Впрочем, я с Вами согласен. Поверх этих процедур можно навесить ООП.

    Главное, это позволит менять реализацию АТД.
    В принципе, предложенный Вами вариант (ARRAY OF SET) вполне пригоден в некоторых случаях. Например, иногда требуются множества без поддержки операций объединения, пересечения и т.п. (В книге Ахо, Ульмана и Хопкрофта "Структуры данных и алгоритмы" они называются "словарями" (Dictionary).)
    Но остаются два дефекта:
    1) клиентский код жестко привязывается к реализации таких множеств, и ее уже нельзя будет поменять;
    2) компилятор не может различить разные типы, имеющие в основе реализации одну структуру данных (такой пример приводил Кодт).

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.