Vlad писал(а):
Ага. Можно. Только не на обероне
О чем и речь. Нечего оберону с его GC делать в ядреном коде. И убогость существующих обероновских ОС только подтверждает сию объективную реальность.
P.S. Напишите Линусу о желании написать что-то ядреное на обероне, он человек прямолинейный, сразу скажет куда пойти
Или почитайте его претензии к C++, как возможного языка для написания GIT (а это всего лишь VCS, не OC).
Мда давно не заглядывал а тут флейм вовсю кыпыт))
2Vlad. Не надо заниматься бесполезными спорами))
Типизированный Оберон безусловно не способен удобно выразить СТАРУЮ
низкоуровневую архитектуру системы с НЕТИПИЗИРОВАННОЙ памятью.
Дык это наоборот замечательно, он для того и был задуман!))
И уж всяко это не является проблемой))
Просто Оберон был предназначен с самого начала для выражения другой,
ТИПИЗИРОВАННОЙ архитектуры памяти которая может делать все то-же самое
что и старая и при этом более высокоуровнева.
System3 и AOS не менее реальны чем Linux. Просто - другие.
И приложения портировать поэтому трудно, нужно перепроектировать.
Линукс же ничем не отличается от того что было до него и поэтому
в него так много старого мусора портировано.
Это не значит что Линукс - достижение. Наоборот.
У Вас проблема наподобие - как запрячь лошадь в автомобиль))
Если Вам нужна интеграция со старыми Си-системами,
если Вам нужен лишь ЯЗЫК, используйте Модулу-2))
Она приемлемо интегрируется с Си.
Оберон-системы же (не языки, а АРХИТЕКТУРЫ СИСТЕМ) как раз и
строились как попытка выяснить что будет если отказаться от
некоторых старых принципов и сделать ВСЕ ИНАЧЕ.
Перепроектируйте то что вы хотели выразить. Без нетипизированной
памяти. И НЕ ИСПОЛЬЗУЯ неявно никаких предварительных условий на
ФИЗИЧЕСКОЕ РАСПОЛОЖЕНИЕ ДАННЫХ В ПАМЯТИ. Работайте с логической структурой.
ЗЫ. С личным менеджером памяти все просто и на Обероне.
И не писали этого тут лишь потому что всем влом))
А все отличие - в том что память должна быть типизированной.
Желательно - жесткий массив структур. Но если хочется можно
и на части порезать вдоль. Тогда число массивов будет не более
числа всех используемых элементарных типов. Байты, целые, ....
Но и проблемы появятся как и с указателями почти.
Любую программу можно переписать в такой манере
заменив указатели на индекс в нужном массиве. Массив из структур
заменить на структуру из массивов. Еще сто лет назад так делали в
Фортране)). И списки и все прочее)) Да, это наверно займет больше памяти.
Так же как struct обычно больше занимает чем union. Ну и что?))
Да, это будет по безопасности нечто среднее между типизированным
статическим массивом структур и полиморфной динамической памятью.
Дык это плата за динамичность и гибкость которую Вы так требуете))
Как разработчик, вы и обязаны выбрать - либо автоматически проверяемая статическая типизация, либо полиморфизм который вы должны не забыть
проверить вручную. А потом ответить за свой выбор перед заказчиком.
ЗЗЫ. Линус не авторитет, как программист он весьма стандартен))
Просто ему повезло, у него было свободное оплаченное институтом
время для разработки))
Вот что верно так это то что у него неплохие организационные
способности и что его юниксоиды распиарили)) в целом он похож на Билла))
...Опенсоурс программы разрабатываются не бесплатно а за счет
организаций которые платят деньги программистам за другую работу))