Ada_Ru форум

Обсуждение языка Ада

Русская ОС

Оставить новое сообщение

Сообщения

Иван Левашев
Русская ОС
2008-05-19 23:52:03

Нет, не Линукс.

 

Сайт проекта http://www.os-rosa.ru/ (в разработке)

 

Информацию о проекте можно узнать здесь: http://www.nip-russia.ru/rosa.html

 

С 14 апреля 2008 г. открыт набор желающих для участия в проекте

«Роса».

 

опыт программирования 3-5 лет (желательно Модула-2/Оберон/Ада, возможно — Delphi, менее предпочтительно — C/C++, C#, Java);

 

Основные языки макетирования:

 

Модула-2 (PIM, ISO)

Оберон(-2)

Компонентный Паскаль

 

Вот если б на месте Модула–2 была бы Ада, то в самый раз. У меня сложилось впечатление, что участники, хоть и упоминают постоянно Аду, но реально с онтопиком не сталкивались. Иначе я не знаю, по каким таким критериям можно предпочесть Модулу–2. Именно Модулу–2, Оберон–2 это не касается; заложенные в нём design time decisions делают его не прямым конкурентом для Ады.

 

Я думаю, они ещё успеют попробовать разные варианты. Особенно с учётом

http://rbogatyrev.livejournal.com/2007/07/16/

 

Мы не зациклены на языках Оберон-семейства и рассматриваем критически

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

 

 

 

Пока большая часть информации в журнале Руслана Богатырёва.

 

 

 

 

Подумал, всем будет интересно.

 

-- If you want to get to the top, you have to start at the bottom

Поглядел я материалы по Росе. Заинтересовался Oberon'ом и его приемниками. Может кто-нибудь дать критику Оберону с точки зрения программиста Ada?

 

-- Olleg Samoylov

Olleg Samoylov wrote:

 

 

Поглядел я материалы по Росе. Заинтересовался Oberon'ом и его

приемниками. Может кто-нибудь дать критику Оберону с точки зрения

программиста Ada?

 

Если смотреть с точки зрения языков как таковых - а зачем критиковать?

Это просто другой язык для других применений.

Точнее, так: преимущества Ады лучше проявляются на больших долго

живущих системах с повышенными требованиями к надежности, в том

числе на встроенных системах реального времени. Преимущества Оберона -

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

 

У Оберона и Ады - заведомо непустое пересечение областей применения, где оба языка

работают достаточно эффективно, и выбор - дело вкуса программиста.

 

Повторяя книжку В.Ш.Кауфмана, скажу, что Ада устроена по принципу сундука -

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

бОльшего количества технологических потребностей, тогда как Оберон

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

набор возможностей.

 

Что мне лично не нравится в Обероне - так это несколько корявый (по сравнению

с Адой) синтаксис. Но это все же мелочь.

 

Если же сравнивать Аду и Оберон с точки зрения индустрии, то в индустрии

Оберона просто нет. Хотя разработчиками языка и Оберон-систем программирования

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

а потому, что так фишка легла.

 

И еще: Ада - это стандарт ИСО (живой, трижды пересмотренный, поддержанный

средствами контроля реализаций). Оберон не стандартизован.

 

Кто что еще скажет?

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

 

Sergey I. Rybin wrote:

Olleg Samoylov wrote:

 

Поглядел я материалы по Росе. Заинтересовался Oberon'ом и его

приемниками. Может кто-нибудь дать критику Оберону с точки зрения

программиста Ada?

 

Если смотреть с точки зрения языков как таковых - а зачем критиковать?

 

Я имел в виду критику в хорошем смысле этого слова. :) Типа "литературная критика", которая вполне может быть и хвалебная.

 

Это просто другой язык для других применений.

Точнее, так: преимущества Ады лучше проявляются на больших долго

живущих системах с повышенными требованиями к надежности, в том

числе на встроенных системах реального времени. Преимущества Оберона -

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

 

Ну "встроенные системы реального времени" и "системы с жесткими ресурсными ограничениями" выглядят как одно и тоже. В чем подвох? В обероне нет поддержки RT в языке? Или есть какое-то фундаментальное разграничение?

 

Повторяя книжку В.Ш.Кауфмана, скажу, что Ада устроена по принципу сундука -

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

бОльшего количества технологических потребностей, тогда как Оберон

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

набор возможностей.

 

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

 

Если же сравнивать Аду и Оберон с точки зрения индустрии, то в индустрии

Оберона просто нет. Хотя разработчиками языка и Оберон-систем программирования

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

а потому, что так фишка легла.

 

Еще меня привлекли ссылки об индустриальном использовании Оберона в проектах российской космонавтики (спутников связи). Т.е. в принципе он захватил нишу Ады, хоть может быть в одном выделенном КБ. Конкурировать с Адой в NATO он конечно не мог, учитывая обязательность использования Ады постановлением конгресса США (если я ничего не путаю).

 

И еще: Ада - это стандарт ИСО (живой, трижды пересмотренный, поддержанный

средствами контроля реализаций). Оберон не стандартизован.

 

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

 

http://oberon2005.ru/tools.html

 

Честно говоря я не знаю, с каким из них было бы корректно сравнивать Аду.

-- Olleg Samoylov

И еще: Ада - это стандарт ИСО (живой, трижды пересмотренный, поддержанный средствами контроля реализаций). Оберон не стандартизован.

 

1) Отсутствует стандартная библиотека. Т.е. хотя бы стандартная

дефакто (черт с ним, с ISO'шным стандартом). Например такая, какая имеется в том же фрипаскале.

 

2) Отсутствует полноценный компилятор именно что Оберона/Оберона-2 с достаточным набором библиотек. Поскольку язык простой, то каждый

норовит его как-нибудь улучшить, расширить и модифицировать. Например это привело к тому, что самая продвинутая и удобная реализация сейчас это BlackBox (среда-компилятор-конструктор. погибче той же еклипсы будет), который на самом деле не оберон, а его диалект производный от Oberon-2 под названием "Компонентный Паскаль". Примечательно, что совместимости у этого диалекта нет ни снизу вверх с оберонами ни

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

 

3) В языке отсутствуют средства для обобщенного программирования. Т.е. дженерики. Что не очень здорово.

 

Ну, а теперь о хорошем:

1) Язык ОЧЕНЬ простой. Всё описание языка (Оберон-2007) занимает 16 страниц. Как следствие имеется возможность его очень быстро изучить и начать на нем писать. А также, при необходимости, вполне реально

реализовать собственный компилятор для каких-то своих специфических нужд. Что не реально для таких языков монстров как Ада и С++ например.

2) Имеется сборщик мусора. Это позволяет создавать достаточно сложные компонентные системы.

 

3) Язык всё же намного безопасней чем С и его производные.

Alexey Veselovsky wrote:

 

Ну, а теперь о хорошем:

1) Язык ОЧЕНЬ простой. Всё описание языка (Оберон-2007) занимает 16

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

начать на нем писать. А также, при необходимости, вполне реально

реализовать собственный компилятор для каких-то своих специфических

нужд. Что не реально для таких языков монстров как Ада и С++ например.

 

Освоить эквивалентное Оберону подмножество Ады тоже не сильно сложною

Другое дело - это подмножество еще надо выделить. Тут нужен квалифицированный

преподаватель-помошник.

 

Ада не такой уж монстр. Ну, например, не нужен вам параллелизм - вы можете

годами пользоваться Адой, не зная ровно ничего про задачи, защищенные записи

и все такое. То же самое с ООП (кстати, на Обероне, если я правильно помню,

без ООП мало что полезного сделаешь). Убрать из языка ООП и параллелизм (это

делается легко и естественно, никакая помощь специалиста не нужна) -

от монстра осталась треть. А я на такой трети 10 лет как пишу, и хватает

(правда, ООП в последние программы таки пролезло...)

 

2) Имеется сборщик мусора. Это позволяет создавать достаточно сложные

компонентные системы.

 

В Аде на основе controlled types можно самому сделать нужный сборщик

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

средой, работает всегда и непонятно как устроен - не есть хорошо

для встроенных систем.

 

3) Язык всё же намного безопасней чем С и его производные.

 

Однозначно! Но в Аде, пожалуй, почетче разрез между статическими

и динамическими проверками, причем проверки жестче и их больше. Но разница

по безопасности между Обероном и Адой на порядки меньше, чем между

ними и С со товарищи.

Olleg Samoylov wrote:

 

Ну "встроенные системы реального времени" и "системы с жесткими

ресурсными ограничениями" выглядят как одно и тоже. В чем подвох? В

обероне нет поддержки RT в языке? Или есть какое-то фундаментальное

разграничение?

 

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

(по меркам Ады) систему быстро и надежно реализовать небольшой

командой, причем система будет работать на не сильно богатой и

шустрой платформе. Одна из идей Вирта - минимализм и экономия всех

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

проектов, которые были типичными в его время. Сейчас понятие

"большой системы" ну ОЧЕНЬ изменилось. Так, GNAT (исходники фронт-енда+

RTL более 50 мегабайт) - это МАЛЕНЬКАЯ программа с точки зрения

современной индустрии. И на современных действительно БОЛЬШИХ

системах виртовская экономия (а в Обероне это один из базовых

принципов построения языка) выходит боком.

 

 

 

> Повторяя книжку В.Ш.Кауфмана, скажу, что Ада устроена по принципу сундука -

> язык стремится предоставить готовые технологические решения для как можно

> бОльшего количества технологических потребностей, тогда как Оберон

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

> набор возможностей.

 

Что в принципе плюс для использования его в качестве языка для

программирования ядра ОС. Да и для программирования встроенных систем

зачастую большой "сундук" не нужных, но обязательных стандартных

библиотек может показаться лишним. Наверное я по натуре минималист и

честно говоря ссылки на "минимализм" оберона привлекли мое внимание.

 

Это зависит. Зависит от того, на какое железо ОС, и каков размер встроенной

системы. Бортовое ПО телефона или автомобиля плевать на чем писать, а вот самолета - уже Ада оказывается СУЩЕСТВЕННО удобнее именно как сундук.

 

И потом - сундук сундуку рознь. Ада устроена как разумный сундук, если

вам чего не надо - его скорее всего нужные вам средства за собой

не потащат.

 

Что до библиотек - так есть же технология bare board.

 

Можно сказать по-другому. Если Оберон в первую очередь экономит

ресурсы среды, то Ада в первую очередь экономит ресурсы,

затрачиваемые на разработку и сопровождение (точнее,

на СОПРОВОЖДЕНИЕ и разработку) систем. А там уж выбирайте,

что важнее в том или ином случае.

 

Еще меня привлекли ссылки об индустриальном использовании Оберона в

проектах российской космонавтики (спутников связи). Т.е. в принципе он

захватил нишу Ады, хоть может быть в одном выделенном КБ. Конкурировать

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

Ады постановлением конгресса США (если я ничего не путаю).

 

Увы, российскую программную индустрию можно (нужно!) не

принимать в рассчет ввиду ее отсутствия в настоящее время.

Отсутствия с точки зрения и по масштабам НОРМАЛЬНОЙ

программной индустрии :((((

 

Что до конгресса США, закон об обязательном использовании Ады

Пентагоном давно отменен.

 

 

 

> И еще: Ада - это стандарт ИСО (живой, трижды пересмотренный, поддержанный

> средствами контроля реализаций). Оберон не стандартизован.

 

Ну да и вообще правильнее было бы наверное говорить не об Обероне, а об

языках семейства Оберон.

 

Так это ж еще хуже! Берешь другую реализацию, и не понимаешь, а

что это такое. А смысл слова "Ада" точно определен и одинаково понятен

ВСЕМ Ада-трансляторам, с которыми стоит иметь дело.

Olleg Samoylov wrote:

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

 

http://oberon2005.ru/tools.html

 

Легкий оффтопик, но мне показалось любопытным. Оказывается Вирта оторвали от академических изысканий и дали вполне конкретную задачу, построить автономный беспилотный вертолет способный самостоятельно передвигаться по намеченному маршруту на базе процессоров ARM. Вирт построил под эту задачу компилятор диалекта Оберон известный как Oberon SA или Oberon Compilter for ARM. Ну и на нем собрал что-то летающее. Но при этом он был вынужден был добавить что-то добавить в этот диалект, например синтаксис для interrupts и traps, а также чего-то выкинуть, мешающее предсказуемой производительности. После чего он пересмотрел первоначальный оберон, в основном с точки зрения отрезания "лишних" деталей и новый оберон может компилиться на компиляторе под ARM (является подмножеством Oberon SA), эта ревизия получила название Oberon-07 (2007 года).

 

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

 

-- Olleg Samoylov

Sergey I. Rybin пишет:

И еще: Ада - это стандарт ИСО (живой, трижды пересмотренный, поддержанный

средствами контроля реализаций). Оберон не стандартизован.

 

Ну да и вообще правильнее было бы наверное говорить не об Обероне, а об

языках семейства Оберон.

 

Так это ж еще хуже! Берешь другую реализацию, и не понимаешь, а

что это такое. А смысл слова "Ада" точно определен и одинаково понятен

ВСЕМ Ада-трансляторам, с которыми стоит иметь дело.

 

Да, это есть. Разные весовые категории. Впрочем, у Лиспа долгое время стандарта не было, и ничего. И среди Оберонов, может быть, доведут до ISO какой–нибудь там Зоннон–2. Когда–нибудь.

 

RB27. Пути восхождения к новой ОС

http://rbogatyrev.livejournal.com/8009.html

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

назвать Norebo (Oberon наоборот).

 

-- If you want to get to the top, you have to start at the bottom

Olleg Samoylov wrote:

 

 

 

Ну "встроенные системы реального времени" и "системы с жесткими

ресурсными ограничениями" выглядят как одно и тоже. В чем подвох?

 

предлагаю наглядный пример двух реально существующих(!) систем реального времени:

1) Транспортный HDSL модем... ну, например, какой-нибудь Watson. Внутри CPU, который на "лету" рулит аппаратным кодированием приема/передачи и поддерживает командный интерпретатор консоли на RS-232. Размеры - с книжку. Это система с жесткими ресурсными ограничениями

2) Коммутационный узел 5ESS от Lucent Technologies, который рулит каналами передачи данных, телефонией и т.д. При этом занимает маш. зал с довольно внушительной площадью. Процессор(-ы), который управляют всем этим хозяйством и решают кучу дополнительных задач, "крутится" под управлением какого-то клона *nix реального времени

2) Имеется сборщик мусора. Это позволяет создавать достаточно сложные компонентные системы.

 

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

 

Кстати, а как сделать такой сборщик мусора? Примерчик какой-нибудь можно? Да, и где бы почитать про пулы памяти в Аде. А то у Гаввы очень

кратенько это всё описано.

 

 

3) Язык всё же намного безопасней чем С и его производные.

 

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

 

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

создает алиас для заданного. Удобно конечно, но и не запрещает

складывать килограммы с километрами.

On Sat, 31 May 2008 00:38:13 +0400, you wrote:

 

2) Имеется сборщик мусора. Это позволяет создавать достаточно сложные

компонентные системы.

 

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

 

Кстати, а как сделать такой сборщик мусора? Примерчик какой-нибудь можно?

 

Где-то я видел сборщик Бема (Boehm) для GNAT-а. Посмотрите в Google, если интересно. (Вообще, есть мнение, и я его разделяю, что сборщики мусора не нужны и вредны. Как по техническим, так и по идеологическим (дизайн) причинам.)

 

Да, и где бы почитать про пулы памяти в Аде. А то у Гаввы очень

кратенько это всё описано.

 

А что там сложного? Есть правда тонкости, например, что адреса

неограниченных массивов "неправильные", и нет простого способа их исправить. Как с этим бороться можно посмотреть в Simple Components. Там-же есть и реализация счетчиков ссылок.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

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

 

Кстати, а как сделать такой сборщик мусора? Примерчик какой-нибудь можно?

 

Где-то я видел сборщик Бема (Boehm) для GNAT-а. Посмотрите в Google, если интересно. (Вообще, есть мнение, и я его разделяю, что сборщики мусора не нужны и вредны. Как по техническим, так и по идеологическим (дизайн) причинам.)

 

Насколько я понял, речь идет не о таком сборщике мусора. Сборщик Бема -- это "Сборщик мусора, который предоставляется средой, работает

всегда и непонятно как устроен".

 

А тут имелся ввиду какой-то сборщик мусора под конкретную задачу...

Да, и где бы почитать про пулы памяти в Аде. А то у Гаввы очень

кратенько это всё описано.

А что там сложного? Есть правда тонкости, например, что адреса

неограниченных массивов "неправильные", и нет простого способа их исправить. Как с этим бороться можно посмотреть в Simple Components.

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

правильном направлении.

 

Там-же есть и реализация счетчиков ссылок.

Ну, счетчики ссылок это то понятно... shared_ptr.

On Sat, 31 May 2008 01:44:54 +0400, you wrote:

 

Насколько я понял, речь идет не о таком сборщике мусора. Сборщик Бема -- это "Сборщик мусора, который предоставляется средой, работает всегда и непонятно как устроен".

 

А тут имелся ввиду какой-то сборщик мусора под конкретную задачу...

 

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

 

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

 

Его нет. В Аде концепция указателей принципиально отлична. В С++ они не типизованы (структурно эквивалентны). В Аде указательный тип - полноценный тип со своими операциями. (заплатку анонимных указательных типов я не считаю. Тем более, что есть мнение, что введение их в Аду 95 было ошибкой).

Помимо прочего, типы указателей дают возможность связать управление памятью не с типом объекта, а с типом указателя. Преимущества очевидны, т.к. один и тот же тип можно размещать где угодно. Что пулы и позволяют. Кроме очевидных применений типа стеков, арен, специфичных алгоритмов выделения памяти, пулы позволяют делать несколько менее очевидные вещи. Например связные списки произвольных типов, не требующие копирования элементов. Можно даже списки задач иметь. Технику этого дела см. там же. Удобно очереди делать, т.к. тип объекта совершенно отвязан от пула (то-бишь контейнера). Все это происходит без базового типа и наследования. Т.е. навешивать свои поля можно на что угодно. Хоть на стандартную строку, хоть на задачу Можно даже наследование от нескольких типов сделать, правда коряво будет.

 

Я пулы очень люблю. Одна из лучших вещей добавленных в Аду 95.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Alexey Veselovsky wrote:

2) Имеется сборщик мусора. Это позволяет создавать достаточно сложные

компонентные системы.

В Аде на основе controlled types можно самому сделать нужный сборщик

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

средой, работает всегда и непонятно как устроен - не есть хорошо

для встроенных систем.

 

Кстати, а как сделать такой сборщик мусора? Примерчик какой-нибудь можно?

Да, и где бы почитать про пулы памяти в Аде. А то у Гаввы очень

кратенько это всё описано.

 

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

 

-- Olleg Samoylov

sve

 

Ну, можно возразить, что в конкретных задачах мусора не бывает. Мусор

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

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

основа аргументации против сборщиков мусора. Проблема не решается, а

откладывается до момента исполнения, в надежде, что мудреный алгоритм

сборки ее решит за программиста. Скорее всего, он (программист) будет

разочарован...

 

в условиях часто меняющихся требований со стороны заказчика в процессе разработки проекта ( бизнес тот на ме сте не стои т ) и это (по крайней мере в моей практике) правило без исключений, код проекта постоянно рефакторится, меняется схема владения и время жизни объектов. в таких условиях гц очень помогает и реализовать проект на жабе бывает на порядок быстрее и проще нежли чем на C++ или Ada.

 

Его нет. В Аде концепция указателей принципиально отлична. В С++ они не

типизованы (структурно эквивалентны). В Аде указательный тип - полноценный

 

структурно эквивалентны и не типизованы - далеко не не одно и тоже. в С++ указатели жестко типизованы.

 

тип со своими операциями. (заплатку анонимных указательных типов я не

считаю. Тем более, что есть мнение, что введение их в Аду 95 было ошибкой).

 

анонимные указатели в Ada - это конечно засада.

 

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

не с типом объекта, а с типом указателя. Преимущества очевидны, т.к. один

и тот же тип можно размещать где угодно. Что пулы и позволяют. Кроме

 

в С++ один и тот же тип можно еще более не принужденно размещать где угодно. например:

 

class A;

 

A* a = ::new A; // по умолчанию

A* a1 = new A; // operator new класса A

 

char a[sizeof(A)] ;

A* a2 = new (a) A; // в любом подходящем куске памяти

 

MySuperPuperAllocator alloc;

A* a3 = new (alloc) A; // используя свой аллокатор ala Адский пул

 

и т.д. на сколько хватит фантазии ...

 

В с++ например легко модно зделать например так:

 

MySuperPuperAllocator1< int > alloc1;

MySuperPuperAllocator2< int > alloc2;

 

std::vector< int, MySuperPuperAllocator1<int> > v( alloc1);

std::vector< int, MySuperPuperAllocator2<int> > v( alloc2);

....

 

а у вас?

On Mon, 2 Jun 2008 17:49:38 +0400, you wrote:

 

в условиях часто меняющихся требований со стороны заказчика в процессе разработки проекта ( бизнес тот на ме сте не стои т ) и это (по крайней мере в моей практике) правило без исключений, код проекта постоянно рефакторится, меняется схема владения и время жизни объектов. в таких условиях гц очень помогает и реализовать проект на жабе бывает на порядок быстрее и проще нежли чем на C++ или Ada.

 

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

>Его нет. В Аде концепция указателей принципиально отлична. В С++ они не >типизованы (структурно эквивалентны). В Аде указательный тип - полноценный

 

структурно эквивалентны и не типизованы - далеко не не одно и тоже. в С++ указатели жестко типизованы.

 

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

 

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

 

в С++ один и тот же тип можно еще более не принужденно размещать где угодно. например:

 

class A;

 

A* a = ::new A; // по умолчанию

A* a1 = new A; // operator new класса A

 

char a[sizeof(A)] ;

A* a2 = new (a) A; // в любом подходящем куске памяти

 

MySuperPuperAllocator alloc;

A* a3 = new (alloc) A; // используя свой аллокатор ala Адский пул

 

Это не аналоги Ады. Указатель в Аде содержит неявную ссылку на пул. С++ примитивные операции new и delete принадлежат типу объекта. В Аде они принадлежат типу указателя. Фактически, разыменовывание в Аде double dispatching, по пулу и по типу цели. (Те случаи, когда в С++ allocator задается "слева", я вообще не рассматриваю. Это - заплатки с целью обхода контракта типа.)

 

В с++ например легко модно зделать например так:

 

MySuperPuperAllocator1< int > alloc1;

MySuperPuperAllocator2< int > alloc2;

 

std::vector< int, MySuperPuperAllocator1<int> > v( alloc1);

std::vector< int, MySuperPuperAllocator2<int> > v( alloc2);

....

 

а у вас?

 

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

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

Для generic контейнеров а-ля С++, которые я кстати очень не люблю, передавайте пул как параметр:

 

generic

Pool : Root_Storage_Pool'Class;

type Element is ...

package Vectors is

...

private

type List is array ...;

type List_Ptr is access List;

for List_Ptr'Storage_Pool use Pool;

...

end Vector;

 

с тем же эффектом.

 

А так, в Аде можно:

 

type Element is ...;

type Ordered_By_Name is access Element;

function "<" (L, R : Sorted_By_Name) return Boolean;

 

type Ordered_By_Id is access Element;

function "<" (L, R : Sorted_By_Id) return Boolean;

 

type Ordered_By_Time is access Element;

function "<" (L, R : Sorted_By_Time) return Boolean;

 

Очень полезно бывает.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

sve

А еще быстрее было бы с помощью генератора случайных чисел... Программы на

жабе, за очень большие деньги, очень медленные, живущие не более суток, но

и не более 1000 кликов я видел.

 

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

 

А теперь вопрос, как исправить такие ошибки в программе с GC? Как если-бы кто-нибудь собирался их исправить... (:-))

 

какие ошибки?

 

Если язык не имеет типов (манифестированных), это означает, что для

связывания необходимо знание структуры. Структурная эквивалентность -

частный случай более общего неявного вывода типов = явного отсутствия оных

(:-)). А вот жесткая типизация тут не причем.

 

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

 

template<class A, typename tag>

struct alias : public A, protected Tag {

typename alias type;

};

 

struct A {

int i;

};

 

A a1, a2;

a1 = a2; // ok same type

 

struct tag0{}; struct tag1{};

 

alias<A, tag0>::type a10, a11;

alias<A, tag1>::type a20;

 

a10 = a20 // oops type error!

a11 = a10 // ok - same type

------------------------------------------

и в тоже время

....

procedure q( p : access Integer ) is ...

end q;

 

type i0_ptr is access all Integer;

type i1_ptr is access all Integer;

i : aliased Integer := 10;

declare

pi0 : i0_ptr := i'access;

pi1 : i1_ptr := i'access;

b : boolean : pi0 = pi1 --- oops! type error - cool!

begin

q(pi0); --- ok???

q(pi1); --- ok???

end;

....

 

(Те случаи, когда в С++ allocator задается "слева", я вообще не рассматриваю. Это - >заплатки с целью обхода контракта типа.)

 

в С++ память не типизирована и конструкция

 

'A* a = new (allocator) A'

 

не что иное как выделение памяти аллокатором 'allocator', с последующей инициализацией этой памяти конструктором объекта A. т.е. что то вроде:

 

mem = allocator.alloc( sizeof(A) )

A::A(mem)

 

причем 'operator new' может быть перегружен для любого конкретного аллокатора. где здесь "заплатки с целью обхода контракта типа"?

 

в большинстве случаев не требуется, т.к. контейнер размешается на стеке или

где надо. В Аде управление памятью ортогонально к типам. Ваши последние

примеры иллюстрируют совершенно противоположный подход.

 

который ничуть не хуже и даже обладает меньшими издержками.

 

Кстати, несовместимый с одами в честь GC, которая требует той же ортогональности.

 

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

On Mon, 2 Jun 2008 20:08:44 +0400, you wrote:

 

>Если язык не имеет типов (манифестированных), это означает, что для >связывания необходимо знание структуры. Структурная эквивалентность - >частный случай более общего неявного вывода типов = явного отсутствия оных >(:-)). А вот жесткая типизация тут не причем.

 

могу ошибаться, но мне всегда казалось что с++ имеет типы

(манифестированные). и даже имея структурную эквивалентность объекты могут отличаться по типу:

 

Но не указатели.

и в тоже время

....

procedure q( p : access Integer ) is ...

end q;

 

type i0_ptr is access all Integer;

type i1_ptr is access all Integer;

i : aliased Integer := 10;

declare

pi0 : i0_ptr := i'access;

pi1 : i1_ptr := i'access;

b : boolean : pi0 = pi1 --- oops! type error - cool!

 

Операция сравнения указателей в Аде не делегируется, как некоторые остальные.

 

Кстати, должна бы. Т.е.

 

task type T is ...

type T0_Ptr is access all T;

type T1_Ptr is access all T;

 

declare

P0 : T0_ptr := X'access;

P1 : T1_ptr := X'access;

B : Boolean : P0 = P1 --- Все равно ошибка, нет "=" для задач

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

 

(Мораль, для получения желаемого эффекта не обязательно избавляться от типов.)

 

begin

q(pi0); --- ok???

q(pi1); --- ok???

 

Я уже говорил, что анонимные указательные типы - ошибка. Структурная эквивалентность это не для Ада. Введены они были исключительно для латания дыр в языке: отсутствие процедур с результатами, отсутствие процедурных типов, отсутствие in-place операций и т.п.

 

>(Те случаи, когда в С++ allocator задается "слева", я вообще не >рассматриваю. Это - >заплатки с целью обхода контракта типа.)

 

в С++ память не типизирована и конструкция

 

'A* a = new (allocator) A'

 

не что иное как выделение памяти аллокатором 'allocator', с последующей инициализацией этой памяти конструктором объекта A. т.е. что то вроде:

mem = allocator.alloc( sizeof(A) )

A::A(mem)

 

причем 'operator new' может быть перегружен для любого конкретного аллокатора. где здесь "заплатки с целью обхода контракта типа"?

 

В словах "не типизирована". Либо управление памятью связано с типом, либо с типом указателя. А если не типизирована, то о каких таких контрактах вообще может идти речь?

 

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

 

который ничуть не хуже

 

Меня он не устраивает. Причины я изложил.

 

и даже обладает меньшими издержками.

 

как то?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

sve

могу ошибаться, но мне всегда казалось что с++ имеет типы

(манифестированные). и даже имея структурную эквивалентность объекты могут

отличаться по типу:

 

Но не указатели.

 

ы? извините Дмитрий, вас сложно понять ... т.е. вы имеете в виду что нельзя создать два различных ТИПА указателя на один value type в С++ ?

 

class A {

id& identity() { ... }

};

 

template<class T>

class T_ptr {

T* ptr_;

public:

explicit T_ptr( T* p) : ptr_: (p) {}

operator -> () const { return ptr_; }

};

 

A* a0 = new A;

T_ptr<A> a1(a0);

 

a0->identity() == a1->indenity(); // ok, same object

a0 == a1; // oops! type error!

a0 = a1; // type error !

a1 = a0; // type error !

assert( typeid(a1) != typeid(a0) ) // ok - different types

 

и в тоже время

....

procedure q( p : access Integer ) is ...

end q;

 

type i0_ptr is access all Integer;

type i1_ptr is access all Integer;

i : aliased Integer := 10;

declare

pi0 : i0_ptr := i'access;

pi1 : i1_ptr := i'access;

b : boolean : pi0 = pi1 --- oops! type error - cool!

 

Операция сравнения указателей в Аде не делегируется, как некоторые

остальные.

 

ага, просто в качестве иллюстрации, что типы разные

 

В словах "не типизирована". Либо управление памятью связано с типом, либо с

типом указателя. А если не типизирована, то о каких таких контрактах вообще

может идти речь?

 

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

 

как то?

 

размер указателя например.

On Tue, 3 Jun 2008 13:57:59 +0400, you wrote:

 

могу ошибаться, но мне всегда казалось что с++ имеет типы

(манифестированные). и даже имея структурную эквивалентность объекты могут отличаться по типу:

 

>Но не указатели.

 

ы? извините Дмитрий, вас сложно понять ... т.е. вы имеете в виду что нельзя создать два различных ТИПА указателя на один value type в С++?

 

Да, т.к. эквивалентность указателей структурная.

 

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

- наследование от целевого типа. Затем - вывод встроенных указателей из ссылочных интерфейсов.

 

Заметьте, что результатом будет связывание всех свойств объекта (указателя) с его типом. Это - модель Ады, или проще сказать, типизованная модель. В Аде 83 она была не доработана. Анонимные указатели Ады 95, вообще, - шаг назад. (Теперь, я ясно выразился?)

 

>В словах "не типизирована". Либо управление памятью связано с типом, либо с >типом указателя. А если не типизирована, то о каких таких контрактах вообще >может идти речь?

 

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

 

Так оно и есть. Только каждый объект здесь - указатель.

 

>как то?

 

размер указателя например.

 

Минуточку, так это как раз то, на что модель Ады и рассчитана! Попробуйте вот эту программку, если компилятор под рукой:

 

with Ada.Text_IO; use Ada.Text_IO;

 

procedure Test_Pointer is

type Thin_Pointer is access all Character;

pragma Convention (C, Thin_Pointer);

 

type Fat_Pointer is access all String;

begin

Put_Line

( Integer'Image (Thin_Pointer'Size)

& Integer'Image (Fat_Pointer'Size)

);

end Test_Pointer;

 

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

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти