Центр информации по операционным системам: Форумы / Другие ОС / Реально ли сделать простую ОСь своими руками?

Центр информации по операционным системам :: Форумы :: Операционные системы :: Другие ОС		<< Предыдущая тема \| Следующая тема >>
Реально ли сделать простую ОСь своими руками?

Переход на страницу 1 2 3 ... 7 [8] 9 ... 11 12 13
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Dron

Пятница 17.11.2006 10:27

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Есть специальные языки паралельного выполнения - но лично я в них большого смысла не вижу. слишком мелкое распаралеливание получается.

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

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

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

Андрей Валяев

Наверх

captain cobalt

Пятница 17.11.2006 11:37

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

alman написал(а) ...
Круто. А на что похож его синтаксис?

На Паскаль.

alman написал(а) ...
Может ли Active Oberon генерить объектные файлы, совместимые с GNU ld?

Нет.
Юниксовый инструментарий не поддерживает (?) межмодульный контроль типов, на который опирается Active Oberon.

alman написал(а) ...
Ну дык, кто бы спорил - так и есть.
А кто, кроме Java машины и NET машины, имеет сборщик мусора?

Вот Active Oberon - имеет.

И без виртуальной машины - прямой компиляцией исходника в машинный код.

И на нём написана целая ось Bluebottle http://dir.osrc.info/Bluebottle

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

alman

Пятница 17.11.2006 17:38

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

grizlyk написал(а) ...

alman написал(а) ...
Дык, я с "пеной у рта" доказывал что синхронизация на уровне объектов - зло. Синхронизировать надо на уровне протоколов. Хотя, есть и исключения.

Это как это?

подробно описано вот здесь:

http://www.l4os.ru/ideology.html

Наверх

alman

Пятница 17.11.2006 17:45

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

captain cobalt написал(а) ...

alman написал(а) ...
Круто. А на что похож его синтаксис?

На Паскаль.

Надеюсь, на Паскаль с объектами?

Наверх

Roman I Khimov

Пятница 17.11.2006 18:11

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

Dron написал(а) ...
Роман, то, что в линуксе все написано так - это просто так у них пошло видимо изначально. У нас вот тоже недавно ушел программист один, он писал ну очень размашисто.. функция на 500 строк с изобилием goto - это норма... а так же изобилие условий, не смотря на C++ глобальный контроль работы через HRESULT, и еще несколько грехов...

Я ж не говорю, что в Linux'е goto направо и налево натыкано. Оно натыкано вот в таком виде, в основном. Исключения редки. И новый goto тебе тоже просто так внести не дадут. Если, конечно, это не вот такой случай.

Вообще, если говорить про Linux, то код в нем довольно неоднородный. Местами сделано просто чудесно, но есть и такие отстойники, что кошмар. Кошмары, в основном, в драйверах, конечно. И в XFS еще...

Dron написал(а) ...
Я могу предложить наверное еще парочку вариантов выхода из ситуации, да только всеравно линукс такой, какой есть. это не проблема линукса, это просто воспитание наверное такое.

Не без этого, конечно.

Греби и улыбайся!

Наверх

grizlyk

Вторник 05.12.2006 17:01

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

grizlyk написал(а) ...
Но при выбрасывании исключения надо вызвать деструкторы для тех локальных объектов, которые уже выделили память и не вызывать для тех, состояние которых неопределено, плюс учесть что исключение может быть вызвано нехваткой памяти и т.п.

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

Я долго старался узнать у кого-либо ответ о причинах такого поведения компилятора, но не смог ничего выяснить, так что лучше делать примерно так:

class T
{
...
protected:
do_destruct()throw(){/* здесь код деструктора */}

public:
virtual ~T()throw(){do_destruct();}

T()throw(exception&):/* здесь код инициализации переменных - членов класса */
{try{
/* здесь код конструктора */
}catch(...){do_destruct();throw;}}
};

Причем следует сделать так, чтобы do_destruct() мог бы быть безопасно вызван повторно и мог бы быть безопасно вызван для полностью проинициализированного, но частично сконструированного объекта.

В принципе, выбор вызова/невызова деструктора компилятором в какой то мере произволен, т.е. каждый вариант поведения имеет как плюсы, так и минусы.

<span class='smallblacktext'>[ Редактирование среда 06.12.2006 09:25 ]</span>

Наверх

Vadim Ushakov

Вторник 05.12.2006 19:14

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

Деструктор не вызывается по вполне логичной причине. Посколько не отработал до конца конструктор, то объект не создан. Значит и деструктор вызывать незачем. Если у вас возникает потребность в таком коде - это неверный дизайн программы. Все такие "деструкторы в конструкторах" должны быть инкапсулированы в деструкторах членов класса.
Если исключение происходит при конструировании объекта, взываются деструкторы всех членов, которые были сконструированны к этому моменту.
Используйте верные идиомы программирования, и у вас не будет потребности вызывать деструкторы того, что не существует.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

grizlyk

Среда 06.12.2006 09:55

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

Vadim Ushakov написал(а) ...
Деструктор не вызывается по вполне логичной причине. Посколько не отработал до конца конструктор, то объект не создан. Значит и деструктор вызывать незачем.

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

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

Vadim Ushakov написал(а) ...
Если у вас возникает потребность в таком коде - это неверный дизайн программы.

Гы-гы-гы. Все зависит от того, что вы понимаете под деструктором.

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

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

Тот же полиморфизм можно рассматривать как "автоматический switch() компилятора по некоему скрытому параметру 'реальный класс объекта' вместо использования 'класса ссылки на объект' ".

Если деструктор не вызывается компилятором автоматически, то программист вынужден вызывать его сам вручную, что плохо, т.к. это приводит к появлению дурацкого метода класса do_destruct(), роль которого может легко исполнять сам деструктор.

Посмотрите ctor/dtor calls and ctor init seq, чтобы не развивать одну дискуссию в разных местах (несмотря на мой ruglish в стиле приезжего ремонтника квартиры: "твоя моя не понимай").

Наверх

Vadim Ushakov

Четверг 07.12.2006 19:04

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

grizlyk, вы не будете, надеюсь, спорить с тем, что семантика языка должна быть логичной и непротиворечивой?
Что мы имеем применительно к С++. Имеются стандартные средства языка для обработаки исключительных ситуаций. При броске исключения идет раскрутка стека и вызываются деструкторы всех автоматических переменных, пока не будет найден обработчик исключения. Язык-то объектно-оринтированный, и базовым понятием является как раз объект, а не черт-знает-что... Принято правило: деструкторы вызываются в порядке, обратном порядку вызова конструкторов. Это логично, поскольку отвечает как раз семантике стека.
Исключение в конструкторе - частный случай. Все для всех объектов, которые к этому моменту были созданы, будут вызваны деструкторы. Но не для того объекта, который в этот момент конструировался - он не СОЗДАН. Здесь имеет место быть транзакционность: либо объект СУЩЕСТВУЕТ, либо это вообще не объект, а мусор в памяти. Так что нету никакого смысла вызвать деструктор для мусора.
Такова семантика, определенна автором языка, и ничего мы тут сделать не можем.
И как показывает практика, данная семантика для решения практических задач пригодна.
Хотя С++ во многих местах нелогичен и дыряв, но что касается семантики создания и разрушения объектов - тут как раз к логичности претензий нет.
Если вас семантика С++ не устраивает - пользуйтесь другим ЯП, который вас устраивает. Вот и всё.
Спорить далее на эту тему не собираюсь, поскольку я считаю, что современный ЯП, предназначенный для индустриального программирования, должен иметь автоматическую сбору мусора, а в таком случае ни о каких деструкторах вообще речь не идет...

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

grizlyk

Пятница 08.12.2006 12:35

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

Vadim Ushakov написал(а) ...
grizlyk, вы не будете, надеюсь, спорить с тем, что семантика языка должна быть логичной и непротиворечивой?

Не буду. Только сразу договоримся, что

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

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

Все остальные преимущества и недостатки в виде "исторических корней" и т.п. неясных причин не стоит принимать во внимание.

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

Vadim Ushakov написал(а) ...
Что мы имеем применительно к С++. ... Это логично, поскольку отвечает как раз семантике стека.

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

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

Vadim Ushakov написал(а) ...
Исключение в конструкторе - частный случай. Все для всех объектов, которые к этому моменту были созданы, будут вызваны деструкторы. Но не для того объекта, который в этот момент конструировался - он не СОЗДАН. Здесь имеет место быть транзакционность: либо объект СУЩЕСТВУЕТ, либо это вообще не объект, а мусор в памяти. Так что нету никакого смысла вызвать деструктор для мусора.

Это хорошо, что вы выделяете конструктор как частный случай чего-то, но выделять конструктор как частный случай обработки стека исключений неправильно, как я уже выше сказал, "Задача исключений - удобный способ разделения, а не реализация конкретного варианта стека исключений."

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

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

Vadim Ushakov написал(а) ...
Такова семантика, определенна автором языка, и ничего мы тут сделать не можем.

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

Vadim Ushakov написал(а) ...
И как показывает практика, данная семантика для решения практических задач пригодна.

Дак это смотря чья практика. Моя практика показывает обратное.

Я думаю, некоторым решением проблемы могло бы быть напрмер использование специального ключевого слова для конструктора, например редкое "auto", которое бы управляло автовызовом деструктора явно.

Одно слово много легче написать чем ловить исключения, писать и вызывать do_destruct()

Вот сравните

T()throw(exception&)auto:a(0){ a=new int[10]; }
~T()throw(){ delete[] a; a=0; }

против

T()throw(exception&):a(0){ try{ a=new int[10]; }catch(...){ do_destruct(); throw; }}
~T()throw(){do_destruct();}
do_destruct()throw(){ delete[] a; a=0; }

Даже без использования "auto" лучше иметь автовызов деструктора, и в "не auto" конструкторе исключение будет поймано, а соостояние восстановлено, ну а "лишний" вызов деструктора не создаст больших проблем, т.к. исключение в конструкторе - это авария, не требует оптимизации за счет нормального режима работы.

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

Наверх

Переход на страницу 1 2 3 ... 7 [8] 9 ... 11 12 13
Перейти: Наверх