OberonCore

через GNOME, которая когда меняется, то и "on" перестает работать...........

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

А про токены не развернёте поподробней, или ссылочки? У меня тут примерно в этом направлении мысли недавно шли.

Над чем медитировать? Если для ядра "динамическая память" и может иметь иной смысл, то "динамические структуры данных" они и в Африке динамические структуры данных, независимо от того, в какой памяти они лежат.

2Илья: поищите статью с названием типа "Reliable software - no more excuses"

2Vlad: динамические структуры данных можно организовать в собственном статическом массиве или нескольких. этакий личный менеджер памяти.

Ага. Можно. Только не на обероне О чем и речь. Нечего оберону с его GC делать в ядреном коде. И убогость существующих обероновских ОС только подтверждает сию объективную реальность.

P.S. Напишите Линусу о желании написать что-то ядреное на обероне, он человек прямолинейный, сразу скажет куда пойти Или почитайте его претензии к C++, как возможного языка для написания GIT (а это всего лишь VCS, не OC).

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

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

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

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

(У меня дежа вю?)

Почему каждая программа должна содержать NEW?
Оберон никого не заставляет использовать динамическую память.
По замыслу и по построению.

А я ничего и не говорил про NEW. Мне все равно как это будет выглядеть (хотя сразу оговорюсь, что SYSTEM я там видеть не хочу). Речь зашла о динамических структурах данных, размещенных в предварительно выделенном куске памяти. Как это будет выглядеть на C/C++ я представляю - там память в непосредственном распоряжении программиста. Покажите как будет выглядеть в таких условиях работа с двунаправленным списком (как простейшим примером динамической структуры данных) на обероне, и я признаю, что я так и не понял что такое оберон и с чем его едят.



Очень сильное заявление. Примерно то же самое, что сказать "C не заставляет нарушать типизацию". Я конечно могу представить себе реализацию рантайма оберон системы без GC, но вот программу без NEW, делающую что-то полезное, фантазии не хватает.

Что же тут сильного? Простой факт.
От опечатки сбор мусора не включится.

Насчет фантазии: у нас тут AVC специалист по ТРИЗ -- там как-то это дело упражняют...

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

Я знаю одну очень полезную программу на Паскале, не использующую new.

Вы ушли от ответа. Просто скажите, что вы не знаете как это сделать (но при этом позволяете себе утверждать, что я чего-то не понимаю в обероне). А если AVC знает, то я думаю он не откажется просветить.

2Vlad со стороны, понятно, что вы пишите прикладные прогарммы, но ниразу не системные.

Память "прикладных" программ для ядра - это огромный статический массив байт. Ядру память то никто не выделяет

NEW - это неявный вызов функции ОС, которая выдает адрес ячейки в этом массиве байт.

Если ядро оперирует статическими переменными, что мешает, тогда писать на Обероне ядро ОС? Кстати никто не запрещает внутри ядра на Обероне использовать свой набор функций типа Alloc|Free, для собственных функций.

А для прикладных програм можно предложить другой набор функций для работы с памятью. И даже со сборщиком мусора

По этому поводу почитайте Кернигана и Ричи "Язык С". Там есть пример простейшего манагера памяти.
(полезно будет заглянуть в исходники Лиункса верси 1.0)

То-то Вирт удивится...

Свои менеджеры памяти я писал, не сомневайтесь.



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



Я не зря хочу пример таких функций (с последующей работой с размещенными таким образом динамическими структурами). Потому что считаю, что из этого примера сразу будет видно, что заниматься такими вещами на обероне - это извращение. Для C я могу с ходу написать:



На С++ с перегруженными new/delete и стандартной библиотекой, поддерживающей понятие аллокатора, это будет еще элегантнее. На обероне - мне страшно представить (пример до сих пор так никто и не привел, только рассуждения о том, что это возможно). Кроме того, как только в обероне появляется явное манипулирование памятью (тот самый Free, который ты упомянул), о какой либо безопасности ("герметичности") говорить уже не приходится. В любом месте все может обрушиться не хуже чем в C. Что остается из достоинств оберона? Цикл WHILE без break? Контроль границ массивов? Сомнительный по эргономичности синтаксис? Та же строгая типизация скорее будет мешать, чем помогать, когда дело дойдет до структур данных типа:

Вирт писал что-то для линуксового ядра на обероне? А что именно?