Есть ли плюсы у Оберона?
От: AVC1  
Дата: 02.11.04 12:32
Оценка: 37 (3) -1
Когда-то в мае я "заглянул" на RSDN и, возможно, частично ответственен за то, что разгорелась такая неожиданно долгая полемика вокруг Оберона.
Причина тому была простая: я взял описание Оберона, взял критическую статью Кернигана "Why Pascal is not my favorite language", затем сопоставил их. Выяснил, что критика Кернигана к Оберону уже неприменима.
Потом установил BlackBox и переписал на Обероне решение системы линейных уравнений методом Гаусса. Выяснилось, что, благодаря открытым массивам, решение для матриц разной размерности формулируется очень легко и без всяких "обходных маневров", в отличие от Си (где пришлось бы пользоваться макросами) и от Си++ (где пришлось бы вводить классы).
Об этом я и написал тогда.
Потом была критика, из которой я узнал, что (из современных языков с Си-подобным синтаксисом) С# (и, похоже, только он один) позволяет сформулировать этот алгоритм столь же элегантно. Я поблагодарил за ценную информацию и "отчалил" по своим делам.
Но вот сейчас заглянул на сайт и с удивлением вижу, что полемика продолжается (и даже с
участием тех же лиц).
Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между
сторонниками "многоязычных" систем и систем, основанных на "моноязыке".
Например, система UNIX — "многоязычная" (тут и Си, и Си++, и Shell, и AWK, и Perl, и прочая, прочая, прочая...). А вот виртовские системы Lilith и Ceres основаны на одном языке (Modula-2 и Oberon соответственно).
Что касается синтаксиса отдельных языков, то, например, шаблоны в Си++ и C# — тоже ведь
"языки в языке".
То, что многоязычие может быть принципиальной позицией можно вычитать из книги Кернигана и Пайка "Практика программирования", там достаточно говориться об использовании
специализированных нотаций.
Так как польза многоязычия видна каждому (удобство), то возникает вопрос: а есть ли польза в использовании одного языка?
Выскажу предположение, что есть, но проявляется она в основном на системном уровне.
Oberon позволяет решать именно системные задачи самыми простыми средствами.
Чтобы пользоваться выгодами компонентного программирования, здесь не нужно изучать талмуды с названиями вроде "Сущность COM" (!?). Достаточно просто импортировать модуль.
Для защиты адресного пространства процесса не нужно опираться на многомощные и чрезмерно
сложные операционные системы, ведь контроль индексов для массивов и "сборка мусора" для
указателей решают эту проблему.
Так что и виртовский подход имеет свои преимущества; особенно для создания надежных
автономных систем.
Re: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.04 12:42
Оценка: +1
Здравствуйте, AVC1, Вы писали:

[поскипано злостно]
AVC>Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между
AVC>сторонниками "многоязычных" систем и систем, основанных на "моноязыке".

Твоя идея очень напоминает противостояние Sun(Java) vs. Microsft (C#? — .Net!):
Первая сказала — пишем один раз, выполняем где угодно, вторая же сказала, что: пишем на чём угодно, но всё будет замечательно друг с другом комбинироваться (компонентность?)
А "моноязычность" имхо — зло!
Ибо чем больше способов выразить то, что нужно реализовать тем лучше. И для каждой конкретной задачи будет выбран наиболее соответствующий, а не единственный (который далеко не обязательно лучший, а просто другого ничего нет )
Re: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 02.11.04 12:44
Оценка: :)
Здравствуйте, AVC1, Вы писали:

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


Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.
Re[2]: Есть ли плюсы у Оберона?
От: Кодт Россия  
Дата: 02.11.04 13:01
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.


Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда.
VxWorks, NevaOS, Win3.x, Win95
Перекуём баги на фичи!
Re[2]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 02.11.04 13:06
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А "моноязычность" имхо — зло!


Мой вопрос в том и заключается: всегда ли "моноязычность" — зло?
Ведь и плюсы, кажется, тоже есть.

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


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

P.S. Прошу заранее прощения, если иногда не смогу отвечать вовремя. Сейчас у меня очень ограниченный доступ к Интернету.

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

Хоар
Re[2]: Есть ли плюсы у Оберона?
От: TheBeard Россия  
Дата: 02.11.04 13:10
Оценка:
Это классический пример выбора между надёжностью и призводительностью.
Если мы готовы абсолютно доверять виртуальной машине Оберона для
_данной_ аппаратной платформы — пожалуйста, имеем быструю систему. Если
такого доверия нет — априори систему разумно считать ненадёжной.

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

Сергей Губанов wrote:

> В оберонистых операционках не нужны вирутальные адресные пространства

> для каждого отдельного процесса — вполне хватает всего одного
> адресного пространства. Это позволяет создавать очень эффективные
> системы (нет временного оверхеда связанного с переключением
> контекстов процессов в режим ядра (там все — в режиме ядра), нет
> оверхеда связанного с копированием данных из одного адресного
> пространства в другое). Например, в
> Aos BlueBottle время
> минимального системного вызова в 30 раз меньше аналогичного в Linux.
Posted via RSDN NNTP Server 1.9 gamma
Re[3]: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.04 13:14
Оценка:
Здравствуйте, AVC, Вы писали:

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


К>>А "моноязычность" имхо — зло!


AVC>Мой вопрос в том и заключается: всегда ли "моноязычность" — зло?

AVC>Ведь и плюсы, кажется, тоже есть.

Приведи хоть 1 реальный плюс именно "моноязычности", плиз, а не просто плюс конкретного языка.
Re[4]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 02.11.04 13:25
Оценка: :)
Здравствуйте, Курилка, Вы писали:

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


Чтобы не ходить далеко, возьмем Оберон-системы. Они основаны на одном хорошо продуманном языке системного программирования (Обероне), и именно потому более надежны и производительны.
Для меня это не праздный вопрос. В последнее время я в основном занимался автономными системами, а в последние два года — системами программирования для таких автономных систем (ассемблеры, компиляторы Си, отладчики).
Здесь важна именно простота и надежность всей системы в целом.

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

Хоар
Re[3]: Есть ли плюсы у Оберона?
От: Kh_Oleg  
Дата: 02.11.04 13:28
Оценка: -1
Здравствуйте, Кодт, Вы писали:

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


СГ>>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.


К>Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда.

К>VxWorks, NevaOS, Win3.x, Win95

Не знаю насчет первых двух операционок, но в первых виндах, записав левые данные в левую область памяти я мог покалечить данные другого процесса, в итоге вся система могла упасть (что, в принципе, мы частенько и наблюдали). В BlueBottle же, благодаря тому, что язык Oberon не позволяет записать данные в чужую область памяти, от защиты памяти можно отказаться, тем самым съэкономив на переключении контекстов. Эта же идея, кстати, заложена и в процессорах Эльбрус. Только в BlueBottle защита сделана на уровне компилятора, а там — на уровне процессора.
Re[2]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 02.11.04 13:32
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.


Думаю, что здесь мы во многом согласны.
Кстати, спасибо за информацию о BlueBottle.

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

Хоар
Re[5]: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.04 13:33
Оценка:
Здравствуйте, AVC, Вы писали:

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


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


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

AVC>Для меня это не праздный вопрос. В последнее время я в основном занимался автономными системами, а в последние два года — системами программирования для таких автономных систем (ассемблеры, компиляторы Си, отладчики).
AVC>Здесь важна именно простота и надежность всей системы в целом.

Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?

Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)
Re[4]: Есть ли плюсы у Оберона?
От: Кодт Россия  
Дата: 02.11.04 13:39
Оценка: +2
Здравствуйте, Kh_Oleg, Вы писали:

К>>Ну и что? Берём любую операционку без защиты памяти. Там тоже не будет оверхеда.

К>>VxWorks, NevaOS, Win3.x, Win95

K_O>Не знаю насчет первых двух операционок, но в первых виндах, записав левые данные в левую область памяти я мог покалечить данные другого процесса, в итоге вся система могла упасть (что, в принципе, мы частенько и наблюдали). В BlueBottle же, благодаря тому, что язык Oberon не позволяет записать данные в чужую область памяти, от защиты памяти можно отказаться, тем самым съэкономив на переключении контекстов. Эта же идея, кстати, заложена и в процессорах Эльбрус. Только в BlueBottle защита сделана на уровне компилятора, а там — на уровне процессора.


В общем, ты прав: если компилятор гарантирует, что стрельбы по памяти не будет, то можно не тратиться на защиту памяти. В этом плане одноязыкие среды допускают ускорение.
Упомянутые VxWorks и NevaOS не навязывают язык разработки (первая — это пародия на *NIX, вторая — на MSDOS) и, в общем-то, могут быть смертельно ранены. Но поскольку они предназначены для встроенных систем, где что попало не запустят, то можно уж как следует отладить и забыть о проблемах.

Однако, кроме стрельбы, есть же уйма способов ввести систему в даун. Например, утечки памяти. (На всякий сборщик мусора найдутся способы).
И здесь изоляция процессов также спасает: замученный сервис можно прибить, перезапустить и продолжить. А если память выжрана на уровне системы — то увы.
Перекуём баги на фичи!
Re[6]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 02.11.04 13:40
Оценка: 1 (1) +1
Здравствуйте, Курилка, Вы писали:

К>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?


К>Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)


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

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

Хоар
Re[6]: Есть ли плюсы у Оберона?
От: Кодт Россия  
Дата: 02.11.04 13:41
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?


А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net
Перекуём баги на фичи!
Re[7]: Есть ли плюсы у Оберона?
От: kavlad Россия http://www.wavesoft.ru
Дата: 02.11.04 13:45
Оценка:
Здравствуйте, Кодт, Вы писали:

К>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net


Он уже есть.
... По ушам лупит Би-2 — Мой друг
Re[7]: Есть ли плюсы у Оберона?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.11.04 13:46
Оценка:
Здравствуйте, Кодт, Вы писали:


К>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net

Для этого еще Net нужно популяризировать выпустив второй дотнет с Лонгхорном.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.04 13:47
Оценка:
Здравствуйте, AVC, Вы писали:

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


К>>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?


К>>Т.е. имхо ты несправедливо перекладываешь ограничения, которые должны быть наложены на ОС на уровень языка, что есть несколько глупо (на мой скромный взгляд)


AVC>Так ведь я и говорю о системах, основанных на одном языке.

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

Когда это "иногда"?
И чем это подтверждено?
Re[7]: Есть ли плюсы у Оберона?
От: kavlad Россия http://www.wavesoft.ru
Дата: 02.11.04 13:48
Оценка:
Здравствуйте, Кодт, Вы писали:

К>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net


Active Oberon for .Net
... По ушам лупит Би-2 — Полковник
Re[8]: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 02.11.04 13:48
Оценка: :))) :)))
Здравствуйте, kavlad, Вы писали:

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


К>>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net


K>Он уже есть.


Т.е. уже ничего ему не поможет
Re[7]: Есть ли плюсы у Оберона?
От: Kh_Oleg  
Дата: 02.11.04 13:50
Оценка: 10 (2)
Здравствуйте, Кодт, Вы писали:

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


К>>Не совсем уверен в справедливости приведённого тобой аргумента, да и не уверен, что Оберон — есть единственный язык дающий такие "гарантии", вопрост, имхо, заключается — в какие накладные расходы выльется реализация этого языка со всеми его замутками. Т.е. имеем по сути IL, т.е. систему аля .NET, но опять же — откуда тут ограничение на число языков, когда в том же .нете его НЕТ?


К>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net

Уже ActiveOberon называется. Но там есть один облом — нету перегрузки методов (функций, процедур). В итоге его расширили, чтобы он мог работать с .NET, но так убого:
System.Console.Write{System.String}("Hello, world!"); (*в фигурных скобках указана сигнатура перегруженного метода, чтобы компилятор знал, что вызывать*)

что работать с ним не хочется. На развалинах Оберона для .NET появился Zonnon. Но тот пока не может добраться до стадии релиза.
Re[8]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 02.11.04 14:13
Оценка:
Здравствуйте, Курилка, Вы писали:

AVC>>Почему это глупо, если иногда это дешевле, надежнее и производительнее?


К>Когда это "иногда"?

К>И чем это подтверждено?

Под "иногда" я имею в виду именно автономные системы.
Под "дешевле" — то, что Вирт на своем примере продемонстрировал как делать системы from scratch минимальными силами.
Под "надежнее" — тот факт, что чем проще базовые принципы и меньше лишнего кода, тем система надежнее.
Под "производительнее" — см. реплику Губанова о BlueBottle.
Кроме того, в книгах по теории компиляции прямым текстом говориться о преимуществе синтаксиса Модулы-2 для оптимизации кода: см. в "красном драконе" Ахо, Ульмана и Сети.

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

Хоар
Re[2]: Есть ли плюсы у Оберона?
От: FR  
Дата: 02.11.04 14:43
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:


СГ>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.


Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?
... << RSDN@Home 1.1.3 stable >>
Re[3]: Есть ли плюсы у Оберона?
От: Кодт Россия  
Дата: 02.11.04 14:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?


Кооперативная/вытесняющая многозадачность и общее/раздельное адресное пространство — вещи пенпердикулярные.

Затраты времени на переключение потоков примерно одинаковы. Сделать вытесняющую из кооперативной можно, например, так: в обработчик прерывания таймера запихнуть вызов функции Sleep(0). (грубо говоря, конечно. На деле — чуть сложнее).
Перекуём баги на фичи!
Re[3]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 02.11.04 15:05
Оценка:
Здравствуйте, TheBeard, Вы писали:

TB> виртуальной машине Оберона


я бы заменил слово "виртуальный" на "runtime system"...
Re[3]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 02.11.04 15:07
Оценка:
Здравствуйте, FR, Вы писали:

FR> А как ... ?


Я же дал ссылку — Aos BlueBottle, смотрите. Работает на нескольких процессорах.
Re[4]: Есть ли плюсы у Оберона?
От: FR  
Дата: 02.11.04 15:11
Оценка:
Здравствуйте, Кодт, Вы писали:

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


FR>>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?


К>Кооперативная/вытесняющая многозадачность и общее/раздельное адресное пространство — вещи пенпердикулярные.


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

К>Затраты времени на переключение потоков примерно одинаковы. Сделать вытесняющую из кооперативной можно, например, так: в обработчик прерывания таймера запихнуть вызов функции Sleep(0). (грубо говоря, конечно. На деле — чуть сложнее).



Если бы было так просто то кооперативных и не было бы
... << RSDN@Home 1.1.3 stable >>
Re[5]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 02.11.04 15:19
Оценка:
Здравствуйте, FR, Вы писали:

FR>Так тут раньше в других ветках проскакивало что в обероне как раз кооперативная


Обероны разные бывают. Оригинальный Оберон разработка которого началась в 1985 году может и был кооперативный я точно сам не знаю. А Aos BlueBottle (Active Object System) датируется что-то около 2000 — 2002 годами, впрочем разработка ведется по сей день (последняя версия от March 12, 2004)
Re[4]: Есть ли плюсы у Оберона?
От: TheBeard Россия  
Дата: 02.11.04 16:09
Оценка: 1 (1) +2
Я так понимаю, в остальном возражений нет? Вот и AVC (думаю, много более
компетентный, чем я) пишет об "экологической нише" Оберона и других
подобных языков.

Возвращаясь к информатике-21, повторю своё мнение: школьникам Оберон как
_язык_ вполне подойдёт, но вот _конкретное исполнение_ BlackBox'а никуда
не годится. Почему — было сказано в изобилии.

Сергей Губанов wrote:

> TB> виртуальной машине Оберона

> я бы заменил слово "виртуальный" на "runtime system"...
Posted via RSDN NNTP Server 1.9 gamma
А вообще-то...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.11.04 02:02
Оценка: 1 (1) +1 :)
Здравствуйте, AVC1, Вы писали:

AVC>Причины этого мне не очень понятны, но хочу предложить одну гипотезу: борьба идет между

AVC>сторонниками "многоязычных" систем и систем, основанных на "моноязыке".
AVC>Например, система UNIX — "многоязычная" (тут и Си, и Си++, и Shell, и AWK, и Perl, и прочая, прочая, прочая...). А вот виртовские системы Lilith и Ceres основаны на одном языке (Modula-2 и Oberon соответственно).
[...]
AVC>Так что и виртовский подход имеет свои преимущества; особенно для создания надежных
AVC>автономных систем.

Кстати, шутки — шутками, наезды — наездами, а Оберон вполне может набрать популярность и "вес", особенно если Оберон-системы будут переносимы c .Net на Oberon-Native. Вот нам, кстати, и своего рода альтернатива .Net появляется. И это уже может быть оченно интересно.

В сущности, а в чём проблема-то? "Паскалистов" — вагон (на пост-советском пространстве, по крайней мере); слово Microsoft, ИМХО, в Европе скоро станет формой ругательства; синтаксис у Оберона простой; опять-таки, имя "Вирт" кое-что значит; с набором популярности Oberon и наработок под него появится тоже немало (в т.ч. — и раскраска синтаксиса ). Я, разумеется, могу ошибаться, но ИМХО, не так уж всё плохо для Оберона должно обстоять. А .Net... ну что .Net... платформа, как и другие.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Есть ли плюсы у Оберона?
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.11.04 02:28
Оценка:
Здравствуйте, FR, Вы писали:

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



СГ>>Вот и я про тоже самое. В оберонистых операционках не нужны вирутальные адресные пространства для каждого отдельного процесса — вполне хватает всего одного адресного пространства. Это позволяет создавать очень эффективные системы (нет временного оверхеда связанного с переключением контекстов процессов в режим ядра (там все — в режиме ядра), нет оверхеда связанного с копированием данных из одного адресного пространства в другое). Например, в Aos BlueBottle время минимального системного вызова в 30 раз меньше аналогичного в Linux.


FR>Интересно. То есть получается кооперативная многозадачность? А как решается подержка нескольких процессоров и распеределение процессорного времени?


Встань, да посмотри:

A possible solution is to require computationally intensive active objects
to release the processor voluntarily by calling a runtime procedure
from time to time. However, this solution is not satisfactory; experience
with tasks in Oberon have shown that this is difficult to coordinate, especially
when active objects make use of other objects to perform their
work. It can also be inefficient, as releasing the processor too often
causes unnecessary overhead, and releasing it too seldom restricts the
progress of other active objects.

A better solution is to use time-slicing, i.e., let the system automatically
preempt long-running processes by setting a timer to interrupt
them.
In this way the system is in control of the frequency of process
switches and the active object programmer does not have to worry
about releasing the processor.

To make the Aos runtime system viable for realtime environments
and responsive in interactive use, a facility must be provided to allow
more important processes to run before less important ones. Therefore
the assignment of relative priorities to processes is foreseen. At any
time, the processes executing will have a priority not lower than that of
all other runnable processes.

There are basically two approaches to scheduling multiple processors:
either each processor is responsible for its own scheduling, or one
processor is responsible for scheduling on all the processors [112]. The
first approach is preferred for its simplicity, symmetry and scalability.


Цит. по: "The Active Object System Design and Multiprocessor Implementation" (она же — PieterMuller.pdf), chapter 4. Active object runtime design, pp 35-36. Жирным я выделил то, что относится непосредственно к твоему вопросу.

Так что, там вытесняющая многозадачность. Притом планировщик вешается на каждый процессор свой собственный.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: А вообще-то...
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 03.11.04 07:50
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> ИМХО, не так уж всё плохо для Оберона должно обстоять.


Дай пожму твою мужественную руку!
Re: А вообще-то...
От: cryozot  
Дата: 04.11.04 09:05
Оценка: +1 :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кстати, шутки — шутками, наезды — наездами, а Оберон вполне может набрать популярность и "вес", особенно если Оберон-системы будут переносимы c .Net на Oberon-Native. Вот нам, кстати, и своего рода альтернатива .Net появляется. И это уже может быть оченно интересно.


ГВ>В сущности, а в чём проблема-то? "Паскалистов" — вагон (на пост-советском пространстве, по крайней мере); слово Microsoft, ИМХО, в Европе скоро станет формой ругательства; синтаксис у Оберона простой; опять-таки, имя "Вирт" кое-что значит; с набором популярности Oberon и наработок под него появится тоже немало (в т.ч. — и раскраска синтаксиса ). Я, разумеется, могу ошибаться, но ИМХО, не так уж всё плохо для Оберона должно обстоять. А .Net... ну что .Net... платформа, как и другие.


"Васюки переименовываются в Нью-Моска, а Москва — в Старые Васюки" (С) Ильф и Петров
... << RSDN@Home 1.1.3 stable >>
Re[5]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 04.11.04 10:14
Оценка: +3
Здравствуйте, TheBeard, Вы писали:

TB>Я так понимаю, в остальном возражений нет? Вот и AVC пишет об "экологической нише" Оберона и других подобных языков.


Думаю, что на этом можно остановиться: у Оберона есть своя "экологическая ниша".
У меня нет цели "рекламировать" Оберон. Я также ценю и другие концептуально целостные системы и языки: UNIX или даже Форт. (Вот только что напомнили о Прологе.)
Но, основываясь на опыте Оберона, хочу сформулировать один тезис.

Разумные ограничения повышают качество ПО: делают его более простым, надежным и эффективным.

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

Хоар
Re[6]: Есть ли плюсы у Оберона?
От: Курилка Россия http://kirya.narod.ru/
Дата: 04.11.04 10:47
Оценка:
Здравствуйте, AVC, Вы писали:

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


В том, то и дело, что именно разумные, а не "святые" ограничения, написанные непререкаемым Виртом, как тут Сергей вещает.
(прошу не принимать близко к сердцу, но у меня именно такое впечатление складывается )
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 04.11.04 12:03
Оценка:
Здравствуйте, Курилка, Вы писали:

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

К>(прошу не принимать близко к сердцу, но у меня именно такое впечатление складывается )

Согласен, что Вирт не "святой", и его вполне можно и нужно критиковать.
Только критика критике рознь. Я вот тут почитал на форуме: Вирт и "looser" и еще бог весть кто. Это несправедливо.
Оберон — красивое решение определенной проблемы (как и Форт, как и UNIX, и т.д.).
Видимо, нам (видящим в Обероне хорошую сторону) просто не удается внятно это выразить.
Так что, хотя бы отчасти, мы сами виноваты.

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

Хоар
Re[6]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 05.11.04 18:04
Оценка:
Здравствуйте, AVC, Вы писали:

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

Абсолютно не согласен с данным утверждением. На практике, даже разумные ограничения делают код непростым, ненадежным. Стоит посмотреть на те же форумы Net. Программисты в погоне за эффективностью пляшут с бубном. Огромное количество времени и сил уходит именно на обход ограничений. Зачастую программа на Net похожа на программу C++ + WinAPI. Только надо приплюсовать еще борьбу с ограничениями, для которой в платформу встроено огромное количество средств.
Мне нравится Net, который принципиально борется со своими ограничениями (к сожалению за некоторыми исключениями). Если среда предоставляет не только концептуально-целостный подход, но и средства их обхода, то мне представляется именно тогда код будет надежным и эффективным. Пускай за это и придется платить "концептуальной" простотой кода. Все равно на 95 процентов это будет действительно "концептуальный" код, но за остальные 5 процентов не придется платить слишком высокой цены. И да умрут танцы с бубном.

PS. Все вышесказанное относится к языкам используемых в промышленной разработке.
PS. Каюсь, не смотрел Оберон, нет времени. Сообщение было ответом на конкретную фразу.
Ничего личного, бизнес есть бизнес.

С уважением, Gleb.
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 05.11.04 22:16
Оценка: 18 (1)
Здравствуйте, GlebZ, Вы писали:

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

GZ>Абсолютно не согласен с данным утверждением. На практике, даже разумные ограничения делают код непростым, ненадежным.

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

GZ>Если среда предоставляет не только концептуально-целостный подход, но и средства их обхода, то мне представляется именно тогда код будет надежным и эффективным. Пускай за это и придется платить "концептуальной" простотой кода. Все равно на 95 процентов это будет действительно "концептуальный" код, но за остальные 5 процентов не придется платить слишком высокой цены. И да умрут танцы с бубном.


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

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

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

Хоар
Re[7]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.11.04 12:48
Оценка: :)
Здравствуйте, AVC, Вы писали:

AVC>Почему это глупо, если иногда это дешевле, надежнее и производительнее?


Ты сейчас с это ОС пишеш или все же с Виндов? Ну, вот и ответь "Почему?".
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.11.04 12:48
Оценка: +1 :)
Здравствуйте, kavlad, Вы писали:

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


К>>А я знаю, как популяризировать Оберон: написать компилятор Oberon.Net


K>Active Oberon for .Net


Ну, вот, кстати, сравните его нововедения и исходный Оберон. Думаю все бует ясно. А еще забавно будет глянуть на то как этот чудо переползет на второй фрэймворк где появятся дженерики. Вот будет забавно послушать Губанова, как он обоснует приклеивание такой некомпонетной вещи как дженерики к Оберону.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.11.04 12:48
Оценка: +1
Здравствуйте, AVC, Вы писали:

AVC>Возьмем конкретное ограничение Оберона: указатели могут указывать только на объекты "кучи".

AVC>Любой Си-программист скажет, что это "ужасное" ограничение. И это понятно, ведь в

Вы со своей любовью сравнивать Оберон с С уже до смеха доводите. С 35 лет. И язык был создан, для того чтобы эффективно биты двигать. А ты с равнивай Оберон с C#. Вот тогла и поглядим где надежность выше. И где удобства больше.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 07.11.04 11:51
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:

VD>А ты с равнивай Оберон с C#. Вот тогла и поглядим где надежность выше.


Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.

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

Хоар
Re[10]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.11.04 13:32
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.


Или креститься от оных сообщений по поводу Оберона.

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

Ну, а что касается сравнения технологий, то это не аргумент. Еще раз повторюсь, что серьезное сравнеие Оберона с Шарпом приведет к явному краху рекламной компании Оберона.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 07.11.04 17:36
Оценка:
VladD2,

> AVC>Ну, что же, будем ожидать сообщений о программах, управляющих работой атомных станций, написанных на C#.


> <...>


> Ну, а что касается сравнения технологий, то это не аргумент. Еще раз повторюсь, что серьезное сравнеие Оберона с Шарпом приведет к явному краху рекламной компании Оберона.


Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[9]: Есть ли плюсы у Оберона?
От: kavlad Россия http://www.wavesoft.ru
Дата: 08.11.04 07:59
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А еще забавно будет глянуть на то как этот чудо переползет на второй фрэймворк где появятся дженерики. Вот будет забавно послушать Губанова, как он обоснует приклеивание такой некомпонетной вещи как дженерики к Оберону.


Я не спец в этом вопросе, но думаю при желании разработчики как-нибудь извернутся
... По ушам лупит Мастер — Дикие гуси
Re: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 08.11.04 19:29
Оценка: 21 (4) -1 :)
Для того, чтобы оценить язык программирования, я знаю только один способ: понять, какую потребность пытается удовлетворить язык программирования, и как разработчик языка справляется с возникающими при этом проблемами.
Насколько я понимаю, цель разработки Оберона — создание простого и надежного языка системного программирования, поддерживающего объектно-ориентированное и компонентное программирование.
Для реализации этих целей Вирт в частности использовал раздельную компиляцию, сборку мусора и даже отказался от обычного понимания программы.
Эти и другие интересные решения я и предполагал обсудить, вовсе не ставя себе целью «сделать Оберону PR». Хотелось только объективно разобраться в его «плюсах» и «минусах». Ведь никто не думает, что Оберон «потеснит» другие языки на PC. У него другая «ниша». Поэтому и тему я сформулировал, на мой взгляд, скромно: «Есть ли плюсы у Оберона».
К сожалению, некоторые участники данного форума (и некоторых других форумов) набросились на Оберон с огульной критикой, не желая, как видно, ни на минуту вообразить, что существуют разные задачи и разные способы их решения. При этом «критика» не слишком разнообразна, постоянно делаются одни и те же утверждения.
Попытаюсь ответить на подобные критические замечания в одном посте.
Получается что-то вроде маленького опуса «Мифы и правда об Обероне».
Для удобства критику выделяю жирным шрифтом.

Оберон – это реинкарнация Паскаля.
Это не так. Паскаль и Оберон были созданы для совершенно разных целей.
Паскаль был задуман как язык обучения структурному программированию.
Оберон – язык системного программирования, его разработка была частью проекта по созданию рабочей станции Ceres. Так что Оберон наследует не Паскалю, а Модуле-2.
При этом Модула-2 была радикально переработа.
Меня именно и заинтересовало, как это было сделано.

В Обероне нет шаблонов. Какой ужас!
В Обероне действительно нет шаблонов и исключений.
Давайте разберемся.
Исключений нет, но ведь нет и утечки ресурсов. Вспомните, в каждом учебнике по Си++ пишут: не забудьте переопределить оператор копирования, если в классе есть члены-указатели. Это называется «глубокое копирование». А в Обероне – любое копирование «глубокое».
Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.
Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си и потомков TCollection из популярного в районе 1990г. TurboVision. Подобные обобщенные контейнеры без шаблонов поставлялись в то же время практически со всеми коммерческими компиляторами Си++.
Есть ли в Обероне средства для их реализации, согласующиеся с его принципами безопасности? Есть. Хочу, например, обратить внимание на языковые конструкции IS и WITH. (Это называется type test и type guard.) В Компонентном Паскале (популярной версии Оберона) интересны с этой точки зрения родовые типы ANYREC и ANYPTR.
Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.) Но употребление шаблонов ведет к двум неприятным последствиям.
Во-первых, многократное дублирование кода, т.к. шаблоны каждый раз компилируются в отдельный код.
Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?
А в Обероне импортирующий модуль перекомпилировать не надо. Это называется раздельная компиляция. Именно этого и нет в языках с шаблонами. (Возможно, какие-то зачатки появились в C# 2.0; но там требуется «компиляция на лету», что не всегда приемлимо.)
Я, конечно, вовсе не противник шаблонов. Они хороши для своих целей и на своем месте (не в Обероне). Но надо помнить, что у каждой языковой конструкции есть своя цена.

Нужно быть профессиональной машинисткой, что бы вводить все эти BEGIN, END, PROCEDURE!
Неужели трудно настроить свой Vim так, чтобы все эти конструкции вводились одновременным нажатием пары клавиш?

Оберон – не язык промышленного программирования.
Утверждают, что популярные ныне языки программирования (C++, C#, Java) – языки промышленного программирования, а вот Оберон – нет.
Интересно получается. На Обероне – ПО для атомных станций, на Java – игрушки для мобильников. Вывод: Java – язык промышленного программирования, а Оберон – академическая игрушка.
Загадочное оно, это промышленное программирование!
Почему то вспоминается реплика из к/ф «В бой идут одни старики»:
«Первая эскадрилья у нас молодцы! Вот как «мессер» завалить, так это вторая. А как чего достать, так это первая!»

Оберон – «отстой», Вирт – “looser”.
«Критика – это когда глупый человек пишет об умном». (Л.Н.Толстой)

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

Хоар
Re[2]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 08.11.04 21:39
Оценка: +1
AVC,

> В Обероне нет шаблонов. Какой ужас!

> В Обероне действительно нет шаблонов и исключений.
> Давайте разберемся.
> Исключений нет, но ведь нет и утечки ресурсов.

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

> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.

> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?

> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)


Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.

> Но употребление шаблонов ведет к двум неприятным последствиям.

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

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

> Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?


Ну, тут может быть более чем одна точка зрения на то, какой вариант надежнее: перекомпилировать весь код, использующий шаблоны, либо же протестировать, чтобы выяснить что та же диагностика не выдается во время исполнения, если статических проверок, как в случае шаблонов, нет.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: Есть ли плюсы у Оберона?
От: GarryIV  
Дата: 08.11.04 22:31
Оценка:
Здравствуйте, AVC, Вы писали:
AVC>В Обероне нет шаблонов. Какой ужас!
AVC>В Обероне действительно нет шаблонов и исключений.
AVC>Давайте разберемся.
AVC>Исключений нет, но ведь нет и утечки ресурсов. Вспомните, в каждом учебнике по Си++ пишут: не забудьте переопределить оператор копирования, если в классе есть члены-указатели. Это называется «глубокое копирование». А в Обероне – любое копирование «глубокое».

Исключения нужны из-за утечки ресурсов? И как же они помогают в борьбе с ними? Наоборот, во многих языках вводятся дополнительные конструкции (using, finally) чтоб избежать утечек при работе с исключениями. На мой взгляд исключения нужны чтоб можно было прервать поток исполнения и оповестить вызывающего о причинах.

Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?
void Func1()
{
  try
  {
    Func2();
  }
  catch(SomeException e)
  {
     // обрабатываем исключение при этом у нас есть доступ к someData
  }
}

void Func2() { Func3(); } // исключения не требуют написания какого либо кода на всех уровнях вызова.

void Func3()
{
  ...
  if(someConditions)
    throw new SomeException(someData);
  ...
}


AVC>Нужно быть профессиональной машинисткой, что бы вводить все эти BEGIN, END, PROCEDURE!

AVC>Неужели трудно настроить свой Vim так, чтобы все эти конструкции вводились одновременным нажатием пары клавиш?

Этот вопрос конечно не принципиальный и грамотная IDE сама нарисует все эти BEGIN, END etc. Только все равно останется толпа лишних буковок. Многим это не нравиться.

AVC>Оберон – не язык промышленного программирования.

AVC>Утверждают, что популярные ныне языки программирования (C++, C#, Java) – языки промышленного программирования, а вот Оберон – нет.
AVC>Интересно получается. На Обероне – ПО для атомных станций, на Java – игрушки для мобильников. Вывод: Java – язык промышленного программирования, а Оберон – академическая игрушка.
AVC>Загадочное оно, это промышленное программирование!
AVC>Почему то вспоминается реплика из к/ф «В бой идут одни старики»:
AVC>«Первая эскадрилья у нас молодцы! Вот как «мессер» завалить, так это вторая. А как чего достать, так это первая!»

Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности. Поэтому тот факт, что Java используется для написания программ для мобильных устройств как раз говорит о том, что это язык промышленного (читай массового) использования. Оберон пока может похвастаться только фактами единичного применения. Если хотяб пол процента создаваемого кода буден написано на Оберон тогда и включим его в список промышленных языков.

AVC>Оберон – «отстой», Вирт – “looser”.

AVC>«Критика – это когда глупый человек пишет об умном». (Л.Н.Толстой)

Тут согласен.
WBR, Igor Evgrafov
Re[3]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 09.11.04 10:07
Оценка: :)))
Здравствуйте, Павел Кузнецов, Вы писали:

ПК> Не очень понял, причем здесь утечки ресурсов...


Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.

ПК> Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?


1) О каких еще ошибках?
2) Кому сообщать?

Ели об ошибках в алгоритме программы, то сообщать надо программисту — для этого есть ASSERT() и HALT().
Re[3]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 09.11.04 10:11
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?


Прямого аналога нет. Впрочем, если Вы объясните смысл приведенного Вами кода, то, быть может, я смогу рассказать Вам как это сделать без использования механизма исключений.
Re[12]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 09.11.04 10:28
Оценка: +2
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.


Совершенно верно. Я вовсе не утверждаю, что Оберон лучше других языков во всех случаях. И не собираюсь отнимать у программистов любимые ими инструменты.
Моей целью изначально было только обсуждение некоторых решений, принятых Виртом при разработке Оберона.
Но, к сожалению, я прихожу к выводу, что не все способны к спокойному и объективному обсуждению. Например, я не понимаю с каким именно моим утверждением спорит Vlad2. Он только повторяет, что C# лучше, чем Оберон. Видимо, во всех случаях, для любых целей. Вообще нет попытки понять логику построения Оберона.
Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?

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

Хоар
Re[4]: О каких еще ошибках?
От: WFrag США  
Дата: 09.11.04 10:43
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.


Именно поэтому в C++ try/finally нет, и в общем-то и не нужны, а в Java без них никуда

И вообще, try/catch/finally — это средство обработки ошибок, а не "прибирания за собой".
Re[3]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 09.11.04 10:51
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Исключения нужны из-за утечки ресурсов? И как же они помогают в борьбе с ними? Наоборот, во многих языках вводятся дополнительные конструкции (using, finally) чтоб избежать утечек при работе с исключениями. На мой взгляд исключения нужны чтоб можно было прервать поток исполнения и оповестить вызывающего о причинах.


Если бы дело обстояло так, как Вы утверждаете, вполне хватало бы старых добрых setjmp и longjmp. Ведь longjmp именно возвращает управление и код ошибки.
Как помогают исключения? Возьмем самый простой, "набивший оскомину" пример: шаблон auto_ptr чистит кучу (т.е. собирает мусор) в случае, если было выброшено исключение. Так и надо делать в Си++.
Но (imho) это не самое простое и не самое системное решение проблемы утечки ресурсов. Например, шаблон auto_ptr не стоит использовать в стандартных контейнерах STL. Это даже запрещается делать.
И, сравните, насколько проще решается эта проблема в виртовском Обероне.
(Специально оговариваюсь: я не считаю, что Оберон лучше других языков всегда и во всем.)

GIV>Мне вот что интересно. Как в Оберон будет выглядеть аналог такого кода?

GIV>
GIV>void Func1()
GIV>{
GIV>  try
GIV>  {
GIV>    Func2();
GIV>  }
GIV>  catch(SomeException e)
GIV>  {
GIV>     // обрабатываем исключение при этом у нас есть доступ к someData
GIV>  }
GIV>}

GIV>void Func2() { Func3(); } // исключения не требуют написания какого либо кода на всех уровнях вызова.

GIV>void Func3()
GIV>{
GIV>  ...
GIV>  if(someConditions)
GIV>    throw new SomeException(someData);
GIV>  ...
GIV>}
GIV>


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

GIV>Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности. Поэтому тот факт, что Java используется для написания программ для мобильных устройств как раз говорит о том, что это язык промышленного (читай массового) использования. Оберон пока может похвастаться только фактами единичного применения. Если хотяб пол процента создаваемого кода буден написано на Оберон тогда и включим его в список промышленных языков.


Наверное, здесь надо просто уточнить термины. Возможно, тогда выяснится, что и спора нет, что он — только терминологический.
Что, на Ваш взгляд, "промышленнее": АЭС или "мобильник"? Ведь АЭС гораздо меньше, чем мобильников.

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

Хоар
Re[5]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 09.11.04 11:15
Оценка:
Здравствуйте, WFrag, Вы писали:

WF> Именно поэтому в C++ try/finally нет


Как это нет, если есть? Они там ВЕЗДЕ есть. И раз они там уже везде есть, то и смысла вводить еще одно ключевое слово finally — уже нет. ЛЮБОЙ блок {} в Си++ по смыслу и есть try/finally — так как все деструкторы локальных объектов должны быть вызваны при выходе из блока даже тогда когда выход из него осуществляется в аварийном режиме.
Re[6]: О каких еще ошибках?
От: WFrag США  
Дата: 09.11.04 11:26
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Как это нет, если есть? Они там ВЕЗДЕ есть. И раз они там уже везде есть, то и смысла вводить еще одно ключевое слово finally — уже нет. ЛЮБОЙ блок {} в Си++ по смыслу и есть try/finally — так как все деструкторы локальных объектов должны быть вызваны при выходе из блока даже тогда когда выход из него осуществляется в аварийном режиме.


Ладно, это философский вопрос. Оставим его.
Re[3]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 09.11.04 12:13
Оценка: :)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не очень понял, причем здесь утечки ресурсов... Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?


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

>> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.

>> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

ПК>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?


Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".
Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

>> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)


ПК>Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.


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

>> Но употребление шаблонов ведет к двум неприятным последствиям.

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

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


Да, существуют такие техники. Самый простой пример: использование косвенных контейнеров с inline функциями приведения void* к конкретному типу указателя.
Но во многих случаях такие техники еще не изобретены.

>> Во-вторых, ненадежность применения шаблонов. Допустим, мы нашли ошибку в реализации популярного шаблона. Казалось бы, «делов то»! Исправил ошибку и все, благо шаблон описан в одном месте. Да не все так просто. Надо перекомпилировать все программы, пользующиеся этим шаблоном. И как это обеспечить?


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


Конечно, точек зрения может быть несколько.
Но мне кажется, что Вы недооцениваете масштаб последствий того, что код, содержащий ошибку, успел разбежаться по тысячам (а для Си++ даже миллионам) отдельных (stand-alone) программ. Они уже откомпилированы, их размноженные копии уже проданы пользователям, и от того, что мы все-таки нашли и исправили ошибку в шаблоне (скорее всего, в каком-нибудь h-файле) пользовательские копии правильными не стали.
Можно было бы надеяться на рассылку "патчей", но на практике этим воспользуются очень немногие "продвинутые" пользователи.
Слава богу, что подавляющее большинство программ, написанных на "промышленных" (языках Си++, Java и C#) на самом деле применяются в сфере услуг, а не в промышленной сфере.

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

Хоар
Re[3]: Есть ли плюсы у Оберона?
От: Трурль  
Дата: 09.11.04 12:26
Оценка: 28 (2) +1 :)
Вообще авторы Оберона вовсе не отрицают пользы родовых типов. Тот же Szyperski сделал пробную реализацию в 97. Просто там где применялся Оберон они не требовались. Сейчас "параметризированные типы" введены в OOC.

Исключений опять же никто не отрицает. Вирт утверждал, просто, что они не должны поминаться всуе, а применяться только для того, для чего предназначены. А посему реализовываться в библиотеках, а не встраиваться в язык.
PROCEDURE Main;
  PROCEDURE Handler (VAR e: SomeException);
  BEGIN
      IF … the failure can be repaired … THEN
       …Repair it…;
      Exceptions.Resume (* return using resume semantics*)
      END;
      (* return using terminate semantics*)
   END Handler;
BEGIN
  ...
  Exceptions.Raise(e);
  ...
END.


GIV>Промышленность нашем случае ИМХО это вовсе не энергетика а IT. Точнее та ее часть, что занимается Software Development. Так вот промышленным может считаться язык, который массово используется в нашей с вами промышленности.

Промышленность, она разная бывает. А разработка, скажем, бортового ПО для ракеты это уже не Software Development? И причем здесь массовость? Это скорее критерий "популярного", а не "промышленного" языка.
Что касается милого вашему сердцу IT. Живет себе такой Stefan Metzeler. Он не бегает по собеседованиям и не рассылает резюме. Вместо этого он в одиночку реализовал порядка 20 проектов за 8 лет. И все на Обероне. И плевать ему на то сколько человек пишут на С++,Java и т.п. Между прочим, среди клиентов: DuPont, Hewlett Packard, ABB, IBM, Royal Bank of Canada, Logitech...
Re[4]: Есть ли плюсы у Оберона?
От: Mamut Швеция http://dmitriid.com
Дата: 09.11.04 12:33
Оценка:
Т>Что касается милого вашему сердцу IT. Живет себе такой Stefan Metzeler. Он не бегает по собеседованиям и не рассылает резюме. Вместо этого он в одиночку реализовал порядка 20 проектов за 8 лет. И все на Обероне. И плевать ему на то сколько человек пишут на С++,Java и т.п. Между прочим, среди клиентов: DuPont, Hewlett Packard, ABB, IBM, Royal Bank of Canada, Logitech...

"Если звезды зажигают, то значит, это кому-нибудь нужно" (с)

Созданный и доведенный до ума язык будет где-нибудь, да востребован. ИМХО
... << RSDN@Home 1.1.4 beta 3 rev. 185>> ... <<Winamp is now playing "Silence">>


dmitriid.comGitHubLinkedIn
Re[4]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 09.11.04 12:59
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Живет себе такой Stefan Metzeler.


Это тот самый? http://www.amadeus-3.com/
Re[5]: Есть ли плюсы у Оберона?
От: Трурль  
Дата: 09.11.04 14:58
Оценка: 12 (1)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Это тот самый? http://www.amadeus-3.com/

Ага,тот самый. Он еще в свободное время свой Amadeus пописывал.
А вот парочка цитат с его сайта.

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. The only languages which were accepted were Ada and Modula-2, thanks to the fact that it had become the only programming language with full ISO standardisation (a very complex process) and certified compilers.


How important is NOTATION?
Fundamental !!!
Try using Roman Numerals for arithmetic calculations.


According to the director of technology of a large US corporation, the average time to train a new C++ programmer is about 3 years, "Which is kind of embarrassing" he added, "since NASA only takes 18 months to train an astronaut."


Some time ago, I did some consulting work for Deutsche Bank and had a chance to work with their development team. When I browsed through the code of their main trading application, it took me a while to figure out that it was actually C++. It looked more like Java or in fact Modula-2, apart from the accolades. Talking to the project leader, I learned that they had very strict guidelines for programming:
— one instruction per line
— every instruction with comment
— NO Multiple inheritance
— NO Macros
— NO Generic modules
— NO Overloading
— NO fancy C-style expressions, only basic operators
— Naming conventions strictly enforced

Re[6]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 09.11.04 15:11
Оценка: +1
Здравствуйте, Трурль, Вы писали:

Т>

How important is NOTATION?
Т>Fundamental !!!
Т>Try using Roman Numerals for arithmetic calculations.



Re[4]: Есть ли плюсы у Оберона?
От: alexeiz  
Дата: 09.11.04 23:33
Оценка: +1
Здравствуйте, AVC, Вы писали:

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


>>> Шаблонов тоже нет. А для чего, кстати, они используются? Для реализации обобщенных (параметризованных) контейнеров и алгоритмов.

>>> Можно ли реализовать их без шаблонов? Можно. Всякий помнит функции qsort и bsearch из стандартной библиотеки языка Си <...>

ПК>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?


AVC>Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".

AVC>Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

В таком случае это что-то вроде dynamic_cast в C++, который является не статической проверкой типов, а динамической.

>>> Какой основной аргумент выдвигается в пользу того, что без шаблонов «жить нельзя»? Их выразительность. Допустим. (Хотя для меня еще выразительнее неспособность компилятора Си++ выдать мало-мальски читабельное диагностическое сообщение о синтаксической ошибке при разборе шаблонов.)


ПК>>Это не является следствием определения языка, а является следствием реализации соответствующих компиляторов. Тот же EDG, на мой взгляд, выдает вполне внятные сообщения об ошибках при инстанцировании шаблонов.


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


Пора уже выбросить на свалку MSVC 6. 7'я версия уже нормально читабельные сообщения выдает.

>>> Но употребление шаблонов ведет к двум неприятным последствиям.

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

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


AVC>Да, существуют такие техники. Самый простой пример: использование косвенных контейнеров с inline функциями приведения void* к конкретному типу указателя.


Кстати сливает реализации не компилятор а линкер. Майкрософтовский линкер делает это на ура. Поэтому и любой компилятор, который создает объектные файлы совместимые с форматом, понимаемым этим линкером, автоматически получает такую возможность. А реализации контейнеров через void* были актуальны разве что десять лет назад.

Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.

AVC>Но во многих случаях такие техники еще не изобретены.


В каких именно случаях?
Re[5]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 10.11.04 10:18
Оценка:
Здравствуйте, alexeiz, Вы писали:

ПК>>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?


AVC>>Такая проверка в Обероне не только возможна, но обязательна. Компилятор Оберона просто не позволит Вам обойти такую проверку, и его не обманешь "приведением типов".

AVC>>Для этого используюся такие средства языка как type test (конструкция IS) и type guard (конструкция WITH).

A>В таком случае это что-то вроде dynamic_cast в C++, который является не статической проверкой типов, а динамической.


Совершенно верно. Я допустил неточность. Хорошо, что Вы ее обнаружили.
Конструкция WITH по существу и есть dynamic_cast.
Я сосредоточился на основной мысли ПК: использование qsort небезопасно, компилятор не может гарантировать корректную работу qsort. Вот я и поспешил его "утешить": в Обероне это безопасно. И потому, к сожалению, слово "статическая" оставил без внимания.
Впрочем, основная мысль о безопасности подобных конструкций в Обероне остается в силе.

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


A>Пора уже выбросить на свалку MSVC 6. 7'я версия уже нормально читабельные сообщения выдает.


По ряду причин, я давно "переполз" на GNU C++.
Если MSVC стал лучше, я только рад, т.к. страдания программистской братии уменьшатся.
Но мое утверждение об усложненности Си++ остается в силе. Чем еще объяснить, что читабельные сообщения об ошибках появились только в 7-й версии? Не злым же умыслом разработчиков компилятора.

A>Кстати сливает реализации не компилятор а линкер. Майкрософтовский линкер делает это на ура. Поэтому и любой компилятор, который создает объектные файлы совместимые с форматом, понимаемым этим линкером, автоматически получает такую возможность. А реализации контейнеров через void* были актуальны разве что десять лет назад.


Говоря о линкере, Вы, наверное, хотели сказать, что во скольких бы файлах проекта не использовался, скажем vector<int>, его код войдет в программу лишь однажды.
Я с этим и не спорю.
Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).
В еще большей степени это относится к шаблонным функциям, ведь, в отличие от классов, общую часть их реализации не поместишь в скрытых предках.

A>Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.


Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.
P.S. А что такое плефора?

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

Хоар
Re[6]: Есть ли плюсы у Оберона?
От: Зверёк Харьковский  
Дата: 10.11.04 11:43
Оценка: +2
Здравствуйте, AVC, Вы писали:

AVC>Говоря о линкере, Вы, наверное, хотели сказать, что во скольких бы файлах проекта не использовался, скажем vector<int>, его код войдет в программу лишь однажды.

AVC>Я с этим и не спорю.
AVC>Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).
AVC>В еще большей степени это относится к шаблонным функциям, ведь, в отличие от классов, общую часть их реализации не поместишь в скрытых предках.

Кода будет ни на копейку не больше, чем если бы ты сам, ручками, написал отдельный класс массива интов, и отдельный класс массива даблов.
Я не прав?

Если прав — то по сравнению с чем разбухание?
сам слушаю и вам рекомендую: Guano Apes — Living In A Lie
FAQ — це мiй ай-кью!
Re[12]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 15:17
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.


Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 15:17
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?


Могу высказать это еще раз. Хочешь?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 10.11.04 15:21
Оценка:
AVC,

> ПК>>>Но в C с этим были связаны определенные проблемы с проверками типизации. Как именно эти проблемы решаются в Обероне? В смысле, возможна ли статическая проверка типов в Обероне для подобных контейнеров и алгоритмов?


> <...>


> Я сосредоточился на основной мысли ПК: использование qsort небезопасно, компилятор не может гарантировать корректную работу qsort. Вот я и поспешил его "утешить": в Обероне это безопасно. И потому, к сожалению, слово "статическая" оставил без внимания.


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

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


Тогда эта безопасность может быть достигнута только обширным тестированием, что достаточно дорого, и необходимость чего вместо статических проверок во время компиляции вряд ли может рассматриваться как более безопасный подход. Хотя, конечно, это более безопасно, чем отсутствие проверок типизации вообще, или очень ослабленные подобные проверки, что имеет место в большинстве реализаций C.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[13]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 10.11.04 16:55
Оценка: 35 (2) +1
Здравствуйте, VladD2, Вы писали:

VD>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.


Господи, и вот эти люди навязывают всем свое мнение об Обероне?!
Ну ведь хоть что-нибудь знал об Обероне! Я о многом не прошу, господи, но пусть Vlad2 хотя бы поинтересуется, что такое Оберон, где и как он применяется, прежде чем выносить свое "компетентное" суждение!
Для особо "одаренных" напоминаю: Оберон и был разработан для создания как операционной системы, так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.

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

Хоар
Re[14]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 10.11.04 16:56
Оценка: +1
Здравствуйте, VladD2, Вы писали:

AVC>>Зачем тогда вообще постить, если он это уже высказал раз двести, употребляя выражения вроде "Оберон — это ЛАЖА"?


VD>Могу высказать это еще раз. Хочешь?


Да ради Бога!
Только цена этому мнению — копейка в базарный день: см. предыдущий пост.

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

Хоар
Re[14]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 22:32
Оценка:
Здравствуйте, AVC, Вы писали:

VD>>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.


AVC>Господи, и вот эти люди навязывают всем свое мнение об Обероне?!

AVC>Ну ведь хоть что-нибудь знал об Обероне! Я о многом не прошу, господи, но пусть Vlad2 хотя бы поинтересуется, что такое Оберон, где и как он применяется, прежде чем выносить свое "компетентное" суждение!
AVC>Для особо "одаренных" напоминаю: Оберон и был разработан для создания как операционной системы,

Выпендривайся меньше. Одаренный, блин.

AVC> так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.


Драйверы и обработчки можно на чем хочешь писать. Вопрос в том, что если среда поддерживает джит, то должен быть фиксированный код который запустит джит-компилятор. Насколько я понял Оберон предпологал наличие джит-компиляции.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 22:32
Оценка: -2
Здравствуйте, AVC, Вы писали:

AVC>Да ради Бога!

AVC>Только цена этому мнению — копейка в базарный день: см. предыдущий пост.

Ошибашся. Это вот вашей рекламе этого убожетсва грош цена. Не удевлюсь если скоро сообщения об Обероне начнут сразу идти в девнал. Пользы от них 0. А задолбали они тут уже всех не нашутку.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 22:32
Оценка:
Я плякаль. Предлагаю двинуть это в Юмор.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 22:32
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Например, блок try ... finally ... end нужен именно для того чтобы "прибрать за собой если вдруг нагадил". В то время как в языке со сборщиком мусора прибирать за собой не нужно.


Господи, какой бред? Ты файлы когда нибудь открывал? А на 0 делить у тебя никогда не приходилось?

ПК>> Мне интересно, а как предполагается сообщать об ошибках в Обероне, кодами возврата/модификацией глобальных переменных?


СГ>1) О каких еще ошибках?




СГ>2) Кому сообщать?




Ты вообще код то писал?

СГ>Ели об ошибках в алгоритме программы, то сообщать надо программисту — для этого есть ASSERT() и HALT().


Да чо уж там. Сделать метод DestroyComputerAndKillAllProgrammers().

PS

Мужики, у меня жувот не резиновй. Ну, столько бреда на квадратный милиметр выдавать просто опасно. Работа же в России остановится.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 23:10
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Слава богу, что подавляющее большинство программ, написанных на "промышленных" (языках Си++, Java и C#) на самом деле применяются в сфере услуг, а не в промышленной сфере.


Нда. Блеск знаний! Ну, так может "гуру" покажет проблемы с типами в C#?

Или расскажет в чем его не устраивает диагностика дженериков?

А вообще, забавная прослеживается тенденция. Говоришь ему "Почему не сравниваешь своей убогий Оберон с современными языками вроде C#?", а в ответ "В С+...". Типа конструктивный разговор. Узнал что в С++ с типобезопасностью фигово и давай на это давить.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.11.04 23:10
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.

AVC>P.S. А что такое плефора?

А это когда человек пишет на языке на 5 лет дольше автора языка.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Есть ли плюсы у Оберона?
От: Трурль  
Дата: 11.11.04 06:23
Оценка: 15 (1)
А вот занятно, что любимый VladD2 COCO/R был написан как раз на Обероне.
Re[7]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 07:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AVC>>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.

AVC>>P.S. А что такое плефора?

VD>А это когда человек пишет на языке на 5 лет дольше автора языка.

Занятно, я пишу уже 15 лет на С++, однако автором себя не считаю!
Что-то случилось в датском королевстве!!!

С уважением, Gleb.
Re[8]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 07:36
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


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


AVC>>>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.

AVC>>>P.S. А что такое плефора?

VD>>А это когда человек пишет на языке на 5 лет дольше автора языка.

GZ>Занятно, я пишу уже 15 лет на С++, однако автором себя не считаю!
GZ>Что-то случилось в датском королевстве!!!

Sorry не 15, обсчитался, 11 лет. Но языку С значительно больше времени, столько не живут.

С уважением, Gleb.
Re[15]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 07:40
Оценка:
Здравствуйте, VladD2, Вы писали:


AVC>> так и всего програмного обеспечения рабочей станции Ceres. Там все программные компоненты, в т.ч. драйвера устройств и обработчики прерываний, написаны на Обероне.


VD>Драйверы и обработчки можно на чем хочешь писать. Вопрос в том, что если среда поддерживает джит, то должен быть фиксированный код который запустит джит-компилятор. Насколько я понял Оберон предпологал наличие джит-компиляции.


C# тоже может писать unmanaged код, поэтому это не концептуальная проблема.

С уважением, Gleb.
Re[15]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Драйверы и обработчки можно на чем хочешь писать. Вопрос в том, что если среда поддерживает джит, то должен быть фиксированный код который запустит джит-компилятор. Насколько я понял Оберон предпологал наличие джит-компиляции.


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

Сейчас ты утверждаешь что насколько ты понял в Обероне есть JIT компилятор.

Я даже не могу сказать что все что ты знаешь об Обероне равно НУЛЮ. Нет не нулю, а это вообще либо отрицательное число, либо мнимая единица.
Re[13]: Как возник первый Оберон
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Павел Кузнецов, Вы писали:


ПК>>Имхо, как раз очень даже хороший аргумент. AVC, насколько я его понял, не говорит о том, что Оберон "лучше", чем C#, а вполне наглядно иллюстрирует важный момент, затрудняющий "серьезное" сравнение данных языков: у них разная область применения.


VD>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.


Вот, почитай как возник первый Оберон:
http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm


ПОСТРОЕНИЕ ВНУТРЕННЕГО ЯДРА
Внутреннее ядро (Inner Core) системы Oberon состоит из файловой системы, загрузчика модулей и средств распределения памяти. Его пять модулей связываются воедино в так называемый файл загрузки (boot file). Здесь мы опишем те шаги, которые позволили сформировать внутренее ядро.

Вряд ли можно поспорить с тем, что началом всех начал для любого программного обеспечения на «голой» машине является начальный загрузчик (boot loader). Поскольку он размещается в ROM-памяти и не может изменяться, он должен быть как можно более компактным. Добиться этого не столь сложно, ведь цель загрузчика проста и хорошо определена. Файл загрузки рабочей станции Ceres состоит из последовательности блоков данных, каждому из которых предшествует его размер и адрес, по которому он должен быть размещен. Формат файла в нотации EBNF выглядит следующим образом:

файл_загрузки = {блок} ноль стартовый_адрес.
блок = размер адрес {байт}.

Начальный загрузчик инициализирует регистры компьютера, очищает память и считывает файл загрузки. Наша первая версия осуществляла считывание через последовательный интерфейс RS-232 и состояла менее, чем из 200 байтов кода. Она была запрограммирована с помощью техники кросс-ассемблирования на компьютере Lilith. Более поздние версии позволяли уже выбирать источник загрузки: винчестер, флоппи-диск или же последовательный канал. Сам файл загрузки создавался загрузочным компоновщиком (boot linker), который также работал на Lilith.

Re[5]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 07:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Господи, какой бред? Ты файлы когда нибудь открывал? А на 0 делить у тебя никогда не приходилось?


Естественно, файлы открывал, а что?

Естественно, на 0 не делил, я так делал: IF f > EPSILON THEN a := b/f; ...
Re[14]: Как возник первый Оберон
От: Клапауций Ниоткуда  
Дата: 11.11.04 08:06
Оценка: +1 :)
Здравствуйте, Сергей Губанов, Вы писали:

СVD>>Да нет у Оберона области применения. Есть только попытки продемонстрировать что его можно использовать. Написать ОС на чистом Обероне невозможно. Все равно загрузчик прийдется написать на языке порождающем нэйтив-коды. А так нет проблем и на Васике ОС написать. Было бы зачем.


СГ>Вот, почитай как возник первый Оберон:

СГ>http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm


СГ>

СГ>ПОСТРОЕНИЕ ВНУТРЕННЕГО ЯДРА
...
Она была запрограммирована с помощью техники кросс-ассемблирования на компьютере Lilith. Более поздние версии позволяли уже выбирать источник загрузки: винчестер, флоппи-диск или же последовательный канал. Сам файл загрузки создавался загрузочным компоновщиком (boot linker), который также работал на Lilith.


Ну и видим, что загрузчик писан на ассемблере а не на Обероне....
Re[8]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 08:14
Оценка:
Здравствуйте, AVC, Вы писали:

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


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

GZ>>Абсолютно не согласен с данным утверждением. На практике, даже разумные ограничения делают код непростым, ненадежным.

AVC>Видимо, надо думать, что отсутствие всяких ограничений делает код простым и надежным?!


GZ>>Если среда предоставляет не только концептуально-целостный подход, но и средства их обхода, то мне представляется именно тогда код будет надежным и эффективным. Пускай за это и придется платить "концептуальной" простотой кода. Все равно на 95 процентов это будет действительно "концептуальный" код, но за остальные 5 процентов не придется платить слишком высокой цены. И да умрут танцы с бубном.


AVC>IMHO, дело обстоит как раз наоборот.

AVC>Мы платим цену как раз за отсутствие концептуальной целостности, т.е. за противоречивость архитектуры ПО, когда "левая рука не знает, что делает правая".
AVC>Отсюда и происходят столь красочно описанные Вами танцы с бубном.

AVC>Возьмем конкретное ограничение Оберона: указатели могут указывать только на объекты "кучи".

AVC>Любой Си-программист скажет, что это "ужасное" ограничение. И это понятно, ведь в Си нет параметров-переменных, надо обязательно использовать указатель.
В первом предложении вы указали ограничение, в следующем вы указали пути обхода. И является ли это ограниением? Примерчик, я бы сказал не очень.
AVC>Так же воспринимается как ограничение контроль индексов при обращению к элементу массива.
Опять, а почему контроль индексов это ограничение, а не дополнение? Вот если нет системы прямого доступа к памяти, вот это ограничение. Писать драйвера уже будет не очень эффективно. Как доступаться к структурам переменной длины.

AVC>Но зато в операционных системах, написанных на Си, приходится уделять много внимания и драгоценных ресурсов защите процессов... друг от друга. А в Оберон-системах объекты вполне могут мирно сосуществовать в одном адресном пространстве, компилятор гарантирует, что они друг другу не помешают.

Вот это меня очень тревожит. Вспоминаю Windows 3.X. Или те же 95 с открытой системной памятью на запись. Устойчивостью не отличались. И хрен его знает как поведет себя среда, если пришла например из порта какая-то белиберда. Гарантировать правильные действия на такую белиберду, я бы поостерегся. У microsoft фикса следует за фиксой.

AVC>В итоге Оберон-система и проще, и эффективнее, и обходится без бубна.
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 11.11.04 08:35
Оценка: -1
Здравствуйте, Зверёк Харьковский, Вы писали:

AVC>>Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).

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

ЗХ>Кода будет ни на копейку не больше, чем если бы ты сам, ручками, написал отдельный класс массива интов, и отдельный класс массива даблов.

ЗХ>Я не прав?

Наверное, я выразился недостаточно ясно.
Я имел в виду, что каждый обобщенный контейнер или обобщенный алгоритм, в идеале должны быть представлены в системе одной единственной копией кода.
Тогда и не будет разбухания кода. Например в Оберон-системе (для рабочей станции Ceres) операционная система занимала менее 200 килобайт, включая компилятор, поддержку сети и т.д. При этом система расширяема на основе объектного и компонентного подхода, и, следовательно, каждое новое расширение требует гораздо меньше кода, чем если бы оно было stand-alone.
Разумеется, я вовсе не утверждаю, что Оберон идеальный язык, или что у Си++ нет своих преимуществ. Просто предлагаю исследовать принципы построения Оберон-систем, со всеми их плюсами и минусами.
В отношении же vector я предлагаю, чтобы в системе был один родовой модуль Vector. Здесь есть и плюсы, и минусы. Давайте их "взвесим".

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

Хоар
Re[6]: Есть ли плюсы у Оберона?
От: alexeiz  
Дата: 11.11.04 08:57
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Говоря о линкере, Вы, наверное, хотели сказать, что во скольких бы файлах проекта не использовался, скажем vector<int>, его код войдет в программу лишь однажды.


Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.

AVC>Я с этим и не спорю.


Ты еще многого не знаешь.

AVC>Но, скажем, vector<double> уже приведет к генерации дополнительного кода (насколько большого зависит от реализации STL).

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

A>>Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.


AVC>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.


Если это не миф, то почему я никогда не встречал количественных сравнений шаблонного кода с эквивалентным нешаблонным, показывающих разбухание? Типичная ситуация для мифа. Только не нужно мне приводить ничего 10 летней давности. Тогда компиляторы были достаточно тупыми.

AVC>P.S. А что такое плефора?


Англицизм: plethora. Я был уверен, что в русском такое слово тоже есть.
Re[8]: Есть ли плюсы у Оберона?
От: mihoshi Россия  
Дата: 11.11.04 08:57
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Наверное, я выразился недостаточно ясно.

AVC>Я имел в виду, что каждый обобщенный контейнер или обобщенный алгоритм, в идеале должны быть представлены в системе одной единственной копией кода.
AVC>Тогда и не будет разбухания кода. Например в Оберон-системе (для рабочей станции Ceres) операционная система занимала менее 200 килобайт, включая компилятор, поддержку сети и т.д. При этом система расширяема на основе объектного и компонентного подхода, и, следовательно, каждое новое расширение требует гораздо меньше кода, чем если бы оно было stand-alone.

Мой идеал почти полностью противоположен Для меня важнее скорость кода, а не размер. Приходится выбирать — либо оверхед (приводящий к замедлению часто в разы, если не на порядок), либо копия имплементации темплейта на каждый набор параметров.
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 11.11.04 09:10
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

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


Я тоже мог бы быть повнимательнее.
Тем более, что, по-моему, это один из самых содержательных вопросов на данном форуме.

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


ПК>Тогда эта безопасность может быть достигнута только обширным тестированием, что достаточно дорого, и необходимость чего вместо статических проверок во время компиляции вряд ли может рассматриваться как более безопасный подход. Хотя, конечно, это более безопасно, чем отсутствие проверок типизации вообще, или очень ослабленные подобные проверки, что имеет место в большинстве реализаций C.


Здесь я пока не соглашусь с Вами.
В отношении Оберона это вряд ли правильный вывод.
То есть из первого (нет статического контроля шаблонов) в данном случае не следует второго (длительного и дорогостоящего тестирования).
Дело в том, что в Обероне Вы в принципе не можете применить какой-либо код к данным "неподходящего" типа.
Получив Ваш пост, я попробовал "обмануть" оксфордский компилятор Оберона: включить в полиморфный контейнер указатель на данные другого типа и сделать с ними что-нибудь "нехорошее". У меня это не получилось. Type guard WITH не позволил этого сделать.
Я стал думать, как вообще "не пустить" несоответствующие данные в контейнер.
Получился следующий набросок:

PROCEDURE guardinsert(p: ANYPTR);
BEGIN
    IF p IS CorrectPtr THEN insert(p) END
END guardinsert;


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

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

Хоар
Re[7]: Есть ли плюсы у Оберона?
От: Kh_Oleg  
Дата: 11.11.04 10:01
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.


А где можно поподробнее узнать про эти чудеса оптимизации?

A>>>Разбухание кода при использовании шаблонов является одним из "мифов" C++. Кто-то тут старается развенчать одни мифы, насаждая при этом плефору других мифов.


AVC>>Разбухание кода в Си++ не миф, хотя, возможно, описывается с некоторыми прецвеличениями. Например, я не имею намерения "клеветать" на языки Си и Си++, на которых пишу уже почти 20 лет. Просто меня интересуют и другие подходы.


A>Если это не миф, то почему я никогда не встречал количественных сравнений шаблонного кода с эквивалентным нешаблонным, показывающих разбухание? Типичная ситуация для мифа. Только не нужно мне приводить ничего 10 летней давности. Тогда компиляторы были достаточно тупыми.


Интересно рассказываете. Миф, значит...

А вот что мы видим в исходниках STLPort 5.0, файл stlport/stl_user_config.h, lines 364-373:

/*
* To reduce the famous code bloat trouble due to the use of templates STLport grant
* a specialization of the vector container for pointer types. So all instanciations
* of vector with a pointer type will use the same implementation based on a vector
* of void*. If you prefer systematical instanciation turn on this macro.
* Remark: This feature is only implemented for compilers supporting partial template
* specialization.
*/

// #define _STLP_DONT_USE_PTR_SPECIALIZATIONS 1


Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.
Re[16]: Есть ли плюсы у Оберона?
От: Mamut Швеция http://dmitriid.com
Дата: 11.11.04 10:05
Оценка:
Здравствуйте, VladD2, Вы писали:

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


AVC>>Да ради Бога!

AVC>>Только цена этому мнению — копейка в базарный день: см. предыдущий пост.

VD>Ошибашся. Это вот вашей рекламе этого убожетсва грош цена. Не удевлюсь если скоро сообщения об Обероне начнут сразу идти в девнал. Пользы от них 0. А задолбали они тут уже всех не нашутку.


Не надо. Из споров тут такие интересные подветки рождаются, что любо-дорого читать. Причем зачастую с Оберонами никак не связанные.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>


dmitriid.comGitHubLinkedIn
Re[8]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:15
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>
AVC>PROCEDURE guardinsert(p: ANYPTR);
AVC>BEGIN
AVC>    IF p IS CorrectPtr THEN insert(p) END
AVC>END guardinsert;
AVC>


В оберон-системах принято поступать еще более сурово:
PROCEDURE guardinsert(p: ANYPTR);
BEGIN
   ASSERT(p IS CorrectPtr); insert(p)
END guardinsert;

Это для того, что тот кто будет использовать процедуру guardinsert() должен будет вызывать ее только с правильными аргументами, в противном случае программа попросту не будет работать.
Re[8]: Есть ли плюсы у Оберона?
От: alexeiz  
Дата: 11.11.04 10:17
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

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


A>>Если это не миф, то почему я никогда не встречал количественных сравнений шаблонного кода с эквивалентным нешаблонным, показывающих разбухание? Типичная ситуация для мифа. Только не нужно мне приводить ничего 10 летней давности. Тогда компиляторы были достаточно тупыми.


K_O>Интересно рассказываете. Миф, значит...


K_O>А вот что мы видим в исходниках STLPort 5.0, файл stlport/stl_user_config.h, lines 364-373:

K_O>

K_O>/*
K_O> * To reduce the famous code bloat trouble due to the use of templates STLport grant
K_O> * a specialization of the vector container for pointer types. So all instanciations
K_O> * of vector with a pointer type will use the same implementation based on a vector
K_O> * of void*. If you prefer systematical instanciation turn on this macro.
K_O> * Remark: This feature is only implemented for compilers supporting partial template
K_O> * specialization.
K_O> */

K_O>// #define _STLP_DONT_USE_PTR_SPECIALIZATIONS 1


K_O>Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.


Меня больше интересуют количественные данные предпочтительно для современных компиляторов. STLPort разрабатывается так, чтобы со многими реализациями C++ получить приемлимую производительность в том числе и достаточно старыми. Я так думаю, STLPort поддерживает gcc 2.95. А он когда вышел? Я даже и не помню.
Re[9]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 10:23
Оценка:
P. S.
На Component Pascal можно даже без ASSERT():
PROCEDURE guardinsert(p: ANYPTR);
BEGIN
   WITH p: CorrectPtr DO insert(p) END
END guardinsert;

В том случае если динамический тип p не CorrectPtr, выполнение будет автоматически остановлено точно также как и при использовании ASSERT().
Re[8]: Есть ли плюсы у Оберона?
От: alexeiz  
Дата: 11.11.04 10:25
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

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


A>>Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.


K_O>А где можно поподробнее узнать про эти чудеса оптимизации?


Мне часто приходится отлаживать release код. Вот там я такое и наблюдаю.
Re[17]: Есть ли плюсы у Оберона?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 11:25
Оценка: +1
Здравствуйте, Трурль, Вы писали:

Т>А вот занятно, что любимый VladD2 COCO/R был написан как раз на Обероне.


Тот самый СОСО, который любим Владом, написан на C#.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[16]: Есть ли плюсы у Оберона?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 11:25
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>C# тоже может писать unmanaged код,


Нет. Ты наверное спутал с unsafe. Это не одно и то же.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[6]: О каких еще ошибках?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 11:25
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Естественно, файлы открывал, а что?


Приведи пример работы с файлом.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[17]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 11:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


GZ>>C# тоже может писать unmanaged код,


AVK>Нет. Ты наверное спутал с unsafe. Это не одно и то же.

Сорри, конечно же unsafe. Просто данный подход концептуально близок к С. Если заделать некоторую компиляцию в unmanagment, то вполне можно писать эффективные системные вещи (типа драйверов или JIT компилятор). Если конечно был бы такой компилятор или режим компиляции (не помню требования что-бы скомпилировать сборку в native). Вышеуказанное сообщение просто утверждало что концептуально это вполне возможно.

С уважением, Gleb.
Re[7]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 12:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


СГ>>Естественно, файлы открывал, а что?


AVK>Приведи пример работы с файлом.


О как! Типа как в детском саду, да?

Delphi:
TYPE 
  TBytes    = ARRAY OF BYTE;

PROCEDURE LoadMemoryFromFile(CONST FileName: STRING; OUT Memory: TBytes);
VAR  FileHandle, MapHandle: THandle;
     FileSize, i: INTEGER;
     StartingAddressOfTheMappedView, p: PByte;
BEGIN
  Memory := NIL;
  StartingAddressOfTheMappedView := NIL;
  FileHandle := SysUtils.FileOpen(FileName, SysUtils.fmOpenRead);
  IF FileHandle = WINDOWS.INVALID_HANDLE_VALUE THEN EXIT;
  TRY
    FileSize := WINDOWS.GetFileSize(FileHandle, nil);
    MapHandle := WINDOWS.CreateFileMapping(FileHandle, nil, PAGE_READONLY, 0, FileSize, nil);
    IF MapHandle = 0 THEN RAISE Exception.Create('Failed to create file mapping!!!');
  FINALLY
    WINDOWS.CloseHandle(FileHandle);
  END;
  TRY
    TRY
      StartingAddressOfTheMappedView := WINDOWS.MapViewOfFile(MapHandle, WINDOWS.FILE_MAP_READ, 0, 0, FileSize);
      IF StartingAddressOfTheMappedView = NIL THEN EXIT;
    FINALLY
      WINDOWS.CloseHandle(MapHandle);
    END;
    SYSTEM.SetLength(Memory, FileSize);
    p := StartingAddressOfTheMappedView;
    FOR i := 0 TO FileSize - 1 DO BEGIN
      Memory[i] := p^;
      INC(p);
    END;
  FINALLY
    WINDOWS.UnmapViewOfFile(StartingAddressOfTheMappedView);
  END;
END;



BlackBox (Component Pascal):
MODULE TestTest;

  IMPORT StdLog, Files; 

  PROCEDURE Test* ();
  VAR  L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
  BEGIN
    L := Files.dir.This("C:\");
    IF L # NIL THEN 
      f := Files.dir.Old(L, "New Text Document.txt", FALSE);
      IF f # NIL THEN
        r := f.NewReader(NIL);
        IF r # NIL THEN 
          WHILE ~r.eof DO r.ReadByte(b); StdLog.Char(CHR(b)) END
        END;
        f.Close();
      END
    END
  END Test;

END TestTest.
Re[8]: О каких еще ошибках?
От: Клапауций Ниоткуда  
Дата: 11.11.04 13:10
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>О как! Типа как в детском саду, да?


СГ>BlackBox (Component Pascal):

СГ>
СГ>MODULE TestTest;

СГ>  IMPORT StdLog, Files; 

СГ>  PROCEDURE Test* ();
СГ>  VAR  L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
СГ>  BEGIN
СГ>    L := Files.dir.This("C:\");
СГ>    IF L # NIL THEN 
СГ>      f := Files.dir.Old(L, "New Text Document.txt", FALSE);
СГ>      IF f # NIL THEN
СГ>        r := f.NewReader(NIL);
СГ>        IF r # NIL THEN 
СГ>          WHILE ~r.eof DO r.ReadByte(b); StdLog.Char(CHR(b)) END
СГ>        END;
СГ>        f.Close();
СГ>      END
СГ>    END
СГ>  END Test;

СГ>END TestTest.
СГ>


И типа этот человек будет говорить о программировании без ошибок ???
Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.

Или может быть вы типа именно этого и хотели ?
Re[8]: О каких еще ошибках?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 13:18
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>О как! Типа как в детском саду, да?


Наверное. За каким чертом в дельфовом варианте вобще try используется непонятно — апишные функции исключений не бросают.

СГ>BlackBox (Component Pascal):

СГ>
СГ>MODULE TestTest;

СГ>  IMPORT StdLog, Files; 

СГ>  PROCEDURE Test* ();
СГ>  VAR  L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
СГ>  BEGIN
СГ>    L := Files.dir.This("C:\");
СГ>    IF L # NIL THEN 
СГ>      f := Files.dir.Old(L, "New Text Document.txt", FALSE);
СГ>      IF f # NIL THEN
СГ>        r := f.NewReader(NIL);
СГ>        IF r # NIL THEN 
СГ>          WHILE ~r.eof DO r.ReadByte(b); StdLog.Char(CHR(b)) END

А что произойдет здесь, если скажем при чтении наткнемся на bad block?

СГ>        END;
СГ>        f.Close();
СГ>      END
СГ>    END
СГ>  END Test;

СГ>END TestTest.
СГ>


А теперь сравни с шарпом:
void Test
{
    try
    {
        using (StreamReader sr = new StreamReader("C:/New Text Document.txt"))
        {
            int c;
            while ((c = sr.Read()) != -1)
                Console.WriteLine((char)c)
        }
    }
    catch
    {
        // do default work
    }
}


Короче и понятнее, не правда ли? При том при любых проблемах с диском файл будет закрыт.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[9]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:33
Оценка:
Здравствуйте, Клапауций, Вы писали:

К>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.


Прости, ошибся. Действительно, на 1 байт больше читается.
Re[10]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 11.11.04 13:33
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>P. S.

СГ>На Component Pascal можно даже без ASSERT():
СГ>
СГ>PROCEDURE guardinsert(p: ANYPTR);
СГ>BEGIN
СГ>   WITH p: CorrectPtr DO insert(p) END
СГ>END guardinsert;
СГ>

СГ>В том случае если динамический тип p не CorrectPtr, выполнение будет автоматически остановлено точно также как и при использовании ASSERT().

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

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

Хоар
Re[17]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 13:52
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Не надо. Из споров тут такие интересные подветки рождаются, что любо-дорого читать. Причем зачастую с Оберонами никак не связанные.


Т.е. Оберон позволяет узнавать новое об остальной индустрии.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 13:52
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>C# тоже может писать unmanaged код, поэтому это не концептуальная проблема.


Анменеджед нельзя. Можно ансэйв. А это две большие разницы, как говорят в Одессе.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 13:52
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Сейчас ты утверждаешь что насколько ты понял в Обероне есть JIT компилятор.


Все порой ошибаются. Все же оберон я смотрел в 97. С тех времен много воды утекло.

СГ>Я даже не могу сказать что все что ты знаешь об Обероне равно НУЛЮ. Нет не нулю, а это вообще либо отрицательное число, либо мнимая единица.


А вот это гнусная демагогия. Уж я точно больше понимаю в Обероне, чем ты в том же Шарпе.

Ты отставл от индустрии лет на 10. И постоянно начинашь обсуждать чужую компетенцию. Просто смешно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 13:52
Оценка: 1 (1) +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Естественно, файлы открывал, а что?


То что их закрывать периодически надо. И если нет нормальной обриботки исключений и блоков защиты, то это превращается в сущий ад.

СГ>Естественно, на 0 не делил, я так делал: IF f > EPSILON THEN a := b/f; ...


Ну, и перед каждым делением по IF-у? И это по-твоему удобная, надежная и безопасная среда программирования?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 13:52
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Занятно, я пишу уже 15 лет на С++, однако автором себя не считаю!

GZ>Что-то случилось в датском королевстве!!!

Случилось. Первое упоминание о С++ это 85-год и компилятор CFront который был препроцессор С. В росси он вообще доступен не был. К тому же до 90-ых С++ на современный был похож очень отдоленно. Небыло шалонов и т.п.

Короче, без знакомства со Сртауструпом писать 20 лет на С++ невозможно в принципе. 15 цифра более реальная, но тоже сомнительная. Я вот с С++ знаком лет 11-12. Причем в те времена надыбал компилятор С++ с большим трудом. Если не ошибаюсь — это был Зортеч С++.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 11.11.04 13:54
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


К>>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.


СГ>Прости, ошибся. Действительно, на 1 байт больше читается.


Переделал:
PROCEDURE Test* ();
VAR  L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
BEGIN
  L := Files.dir.This("C:\");
  IF L # NIL THEN 
    f := Files.dir.Old(L, "New Text Document.txt", FALSE);
    IF f # NIL THEN
      r := f.NewReader(NIL);
      IF r # NIL THEN
        LOOP 
          r.ReadByte(b);
          IF r.eof THEN EXIT END;
          StdLog.Char(CHR(b)) 
        END;
      END;
      f.Close();
    END
  END
END Test;
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 11.11.04 14:25
Оценка: -1
Здравствуйте, alexeiz, Вы писали:

A>Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.


Я прямо весь в сомнениях. Пишу простой код (прошу прощения за стиль — нет времени),
компилирую с помощью MSVC для двух векторов целых чисел в первом случае, и для вектора целых и char*. Пока я с векторами ничего не делаю, размер и правда одинаковый. Как только добавляю хоть какую-то функциональность (sort()), сразу разница в 4K.

#include <cstdio>
#include <vector>
#include <algorithm>

using namespace std;

int main()
{
    vector<int> vi(100);
    sort(vi.begin(), vi.end());
#if 1
    vector<int> vi2(100);
    sort(vi2.begin(), vi2.end());
#else
    vector<char *> vs(100);
    sort(vs.begin(), vs.end());
#endif
    return 0;
}



A>Ты еще многого не знаешь.


Ну, ничего, есть же RSDN.
Здесь каждый второй — Мюнхгаузен.

AVC>>P.S. А что такое плефора?

A>Англицизм: plethora. Я был уверен, что в русском такое слово тоже есть.

Опять же вспоминается к/ф "В бой идут одни старики".

- Рахмат!
— Что?
— Спасибо по-узбекски.
— А... Здоровеньки булы!
— Что?
— Пожалуйста по-украински.

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

Хоар
Re[9]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 14:35
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Короче, без знакомства со Сртауструпом писать 20 лет на С++ невозможно в принципе. 15 цифра более реальная, но тоже сомнительная. Я вот с С++ знаком лет 11-12. Причем в те времена надыбал компилятор С++ с большим трудом. Если не ошибаюсь — это был Зортеч С++.

Занятно, труды должны быть очень большие. На каждом углу продавались дискеты с Borland C++. C которого собственно начинал где-то 92-93 года. MFC датируется серединой 92 года. Насчет 15 извинился.

С уважением, Gleb.
Re[8]: Есть ли плюсы у Оберона?
От: Кодт Россия  
Дата: 11.11.04 14:44
Оценка:
Здравствуйте, AVC, Вы писали:

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


A>>Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.


Ну, это чересчур сильное утверждение. Боюсь, что не так всё сказочно. Оставлять единственную копию предметов, имеющих _declspec(any), — это да. А вот чтобы до побайтного сравнения кода...

AVC>Я прямо весь в сомнениях. Пишу простой код (прошу прощения за стиль — нет времени),

AVC>компилирую с помощью MSVC для двух векторов целых чисел в первом случае, и для вектора целых и char*. Пока я с векторами ничего не делаю, размер и правда одинаковый. Как только добавляю хоть какую-то функциональность (sort()), сразу разница в 4K.

Потому что std::sort тащит за собой
* итераторы — std::vector<T>::iterator
* компаратор — std::less<T>
* собственно алгоритм

Кстати, сейчас повторил твой эксперимент. Эти 4К — какая-то отладочная информация. Если включить оптимизацию -Ox, то размер файла не меняется.
Перекуём баги на фичи!
Re[9]: О каких еще ошибках?
От: Трурль  
Дата: 11.11.04 14:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А теперь сравни с шарпом:

AVK>
AVK>void Test
AVK>{
AVK>    try
AVK>    {
AVK>        using (StreamReader sr = new StreamReader("C:/New Text Document.txt"))
AVK>        {
AVK>            int c;
AVK>            while ((c = sr.Read()) != -1)
AVK>                Console.WriteLine((char)c)
AVK>        }
AVK>    }
AVK>    catch
AVK>    {
AVK>        // do default work
AVK>    }
AVK>}
AVK>


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


type "C:/New Text Document.txt"

А так еще короче и понятнее, не правда ли?
Re[10]: О каких еще ошибках?
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.11.04 14:50
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>
Т>type "C:/New Text Document.txt"
Т>

Т>А так еще короче и понятнее, не правда ли?

Ага, а теперь приведи исх. код программы type — посмотрим, что проще и понятнее
Re[10]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 14:52
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


VD>>Короче, без знакомства со Сртауструпом писать 20 лет на С++ невозможно в принципе. 15 цифра более реальная, но тоже сомнительная. Я вот с С++ знаком лет 11-12. Причем в те времена надыбал компилятор С++ с большим трудом. Если не ошибаюсь — это был Зортеч С++.

GZ>Занятно, труды должны быть очень большие. На каждом углу продавались дискеты с Borland C++. C которого собственно начинал где-то 92-93 года. MFC датируется серединой 92 года. Насчет 15 извинился.

Ты явно все перепутал. В 92 даже Visual C++ не было. А МФЦ вошла в его состав. 93-ий — это год появления виндовс 3.1.

Borland C++ вышел, врое как, намного позже. В те времена был Турбо С/С++. И найти компилятор С++ в 90 было ой как не просто. Лично я искал с месяц. Причем все тогдашние компиляторы были долеки от совершенства. А 90-ый — это 14 лет назад. А не как не 20.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: О каких еще ошибках?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.11.04 15:06
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>
Т>type "C:/New Text Document.txt"
Т>

Т>А так еще короче и понятнее, не правда ли?

Это ты к чему? Постебаться охота или есть что сказать по делу?
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[11]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 11.11.04 15:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты явно все перепутал. В 92 даже Visual C++ не было. А МФЦ вошла в его состав. 93-ий — это год появления виндовс 3.1.

здесь
Может ты спутал, кажется в 93 году вышла Windows 3.11, наиболее глючная версия из когда либо выпущенных версий Windows 3.0. Но Windows все таки начался с Windows 3.0 в 1990 году. Кстати, была еще Windows 2.0 которая при мне упешно юзалась на всяких XT. Мужики как-то запускали на пентюхе, работает, правда со скоростью как на XT.

VD>Borland C++ вышел, врое как, намного позже. В те времена был Турбо С/С++. И найти компилятор С++ в 90 было ой как не просто. Лично я искал с месяц. Причем все тогдашние компиляторы были долеки от совершенства. А 90-ый — это 14 лет назад. А не как не 20.

Насчет совершенства, то тогда еще много чего не было, типа RTTI и шаблонов. Так их и в спецификации тогда не было.
Borland C++ 2.0 у меня лежал купленный практически с момента выхода(а это произошло еще до того как я пришел на ту работу в 1992). Затем был куплен Visual C++ 1.0 и я попрощался с OWL. Был еще Watcom, но когда он появился уже не помню (где-то 93 кажется).

С уважением, Gleb.
Re[8]: Есть ли плюсы у Оберона?
От: Sergey J. A. Беларусь  
Дата: 11.11.04 15:45
Оценка:
Здравствуйте, AVC, Вы писали:

A>>Нет. Линкер умеет объединять любой сходный код. Например vector<int> и vector<long> и vector<void*> и vector<vector<int>*> имеют один и тот же код (на 32 битной платформе). Поэтому линкер оставит только одну копию кода для всех этих template instantiations. Более того, допустим у тебя есть две функции, которые на C++ выглядят абсолютно по-разному, но после обработки компилятором и оптимизатором из них получается один и тот-же ассемблерный код. Линкер оставит только одну копию этого кода.


AVC>Я прямо весь в сомнениях. Пишу простой код (прошу прощения за стиль — нет времени),

AVC>компилирую с помощью MSVC для двух векторов целых чисел в первом случае, и для вектора целых и char*. Пока я с векторами ничего не делаю, размер и правда одинаковый. Как только добавляю хоть какую-то функциональность (sort()), сразу разница в 4K.

AVC>
...
AVC>


Увы кажется не объединяет. Попробовал на VC6.0 и 7.0 — Если запустить релиз в отладчике то видно, что вызываются разные ф-ии.
Попробовал разные опции оптимизатора....
Я — свихнувшееся сознание Джо.
Re[9]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 11.11.04 16:12
Оценка:
Sergey J. A.,

> Увы кажется не объединяет. Попробовал на VC6.0 и 7.0


Попробуй VC 7.1 + whole program optimization.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[10]: О каких еще ошибках?
От: WolfHound  
Дата: 11.11.04 16:25
Оценка: +4
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Прости, ошибся. Действительно, на 1 байт больше читается.

О чем тебе уже все много раз говорили... Людям свойственно ошибаться... И как следствие нужен отладчик и тд и тп...
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Есть ли плюсы у Оберона?
От: Sergey J. A. Беларусь  
Дата: 11.11.04 16:44
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

>> Увы кажется не объединяет. Попробовал на VC6.0 и 7.0


ПК>Попробуй VC 7.1 + whole program optimization.


Тэкс. Похоже для sort он не делает слияние, но методы самого вектора он мержит:
#include <cstdio>
#include <vector>
#include <algorithm>

using namespace std;

int main()
{
 vector<int> vi(100);
 vector<void *> vs(100);

 __asm {int 3}

 vi.size();                          // Одна ф-ия
 vs.size();

 vi.push_back(0x666);                // Одна ф-ия
 vs.push_back((void *)0x666);

 sort(vi.begin(), vi.end());        // Разные
 sort(vs.begin(), vs.end());

 return 0;
}


Возможно, если ещё что-то подкрутить то сможет смержить и sort, но времени нету на ексерименты.
Я — свихнувшееся сознание Джо.
Re[6]: О каких еще ошибках?
От: Шахтер Интернет  
Дата: 11.11.04 17:59
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

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


VD>>Господи, какой бред? Ты файлы когда нибудь открывал? А на 0 делить у тебя никогда не приходилось?


СГ>Естественно, файлы открывал, а что?


СГ>Естественно, на 0 не делил, я так делал: IF f > EPSILON THEN a := b/f; ...


При работе с плавающей арифметикой избежать возможности возникновения исключений по переполнению невозможно в принципе в любых мало-мальски серьёзных задачах. Так что изображённый выше подход не катит совершенно -- мало того, что он черезвычайно громоздкий, так он ещё и не решает проблемы. Без исключений тут не обойдешься.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[9]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 19:57
Оценка: +1
Здравствуйте, Клапауций, Вы писали:

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


СГ>>О как! Типа как в детском саду, да?


СГ>>BlackBox (Component Pascal):

СГ>>
СГ>>MODULE TestTest;

СГ>>  IMPORT StdLog, Files; 

СГ>>  PROCEDURE Test* ();
СГ>>  VAR  L: Files.Locator; f: Files.File; r: Files.Reader; b: BYTE;
СГ>>  BEGIN
СГ>>    L := Files.dir.This("C:\");
СГ>>    IF L # NIL THEN 
СГ>>      f := Files.dir.Old(L, "New Text Document.txt", FALSE);
СГ>>      IF f # NIL THEN
СГ>>        r := f.NewReader(NIL);
СГ>>        IF r # NIL THEN 
СГ>>          WHILE ~r.eof DO r.ReadByte(b); StdLog.Char(CHR(b)) END
СГ>>        END;
СГ>>        f.Close();
СГ>>      END
СГ>>    END
СГ>>  END Test;

СГ>>END TestTest.
СГ>>


К>И типа этот человек будет говорить о программировании без ошибок ???

К>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.

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

Для примера тот же код на C#:
using System;
using System.IO;
using System.Text;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            string path = args[0];
            using (StreamReader reader = new StreamReader(path, Encoding.Default))
            {
                Console.WriteLine(reader.ReadToEnd());
            } // вот здесь файл будет закрыт даже если было исключение.
        }
        catch (IndexOutOfRangeException)
        { // Суда прийдем если args не содержит аргументов
            Console.WriteLine("Enter path to file, lease.");
        }
        catch (Exception ex)
        { // А сюда в случае любой ошибки. Так что если файла нет или еще что, 
            // то незабудем сказать об этом пользователю.
            Console.WriteLine(ex.Message);
        }
    }
}
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 19:57
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Прости, ошибся. Действительно, на 1 байт больше читается.


Гы. Значит и на 0 можешь поделить. А как же надежность программы? Одна ошиблка и ОС в дауне?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка: 6 (1)
Здравствуйте, Сергей Губанов, Вы писали:

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


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


К>>>Привёл пример и на тебе. На eof нужно было проверять после чтения, иначе появляется дополнительный байт в конце, что и можно наблюдать.


СГ>>Прости, ошибся. Действительно, на 1 байт больше читается.


СГ>Переделал:

...

А теперь сравни с Шарпом ради хохмы :
using (StreamReader reader = new StreamReader(path, Encoding.Default))
{
        Console.WriteLine(reader.ReadToEnd());
} // вот здесь файл будет закрыт даже если было исключение.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

СГ>>Прости, ошибся. Действительно, на 1 байт больше читается.

WH>О чем тебе уже все много раз говорили... Людям свойственно ошибаться... И как следствие нужен отладчик и тд и тп...

Да ладно уж отладчик. Хотя бы исключения и средства их обработки. А то ж смешно смотреть на супер надежный язык выподающий в осадок от первого отсуствующего файла или деления на 0 в совершенно несущесвтенном месте.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка: +1
Здравствуйте, Трурль, Вы писали:

Т>
Т>type "C:/New Text Document.txt"
Т>

Т>А так еще короче и понятнее, не правда ли?

На такую демагогию леко отвтить:
DoAll();

Так еще понянтее, не правда ли?

ЗЫ

Лучше по делу чего уного сказал бы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка:
Здравствуйте, Kh_Oleg, Вы писали:

K_O>Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.


СтлПорт рассчитан на компиляцию на самых разных компиляторах. Для VC 7+ и Intel C++ подобная фигня не нужна.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Есть ли плюсы у Оберона?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.04 20:44
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Опять же вспоминается к/ф "В бой идут одни старики".


Тебе старики случаем не советовали оптимизацию включать?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Есть ли плюсы у Оберона?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 04:20
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В том случае если динамический тип p не CorrectPtr, выполнение будет автоматически остановлено точно также как и при использовании ASSERT().
Ух как зашибись. То есть опять — устойчивость системы гарантируется через test coverage и прочие пироги; т.е. путем геморроя. Намекну, что в С++, С# 2.0 и Java 1.5 в случае, если статический тип не CorrectPtr, то компиляция будет автоматически остановлена и сообщение об ошибке попадет сразу тому, кто ее сделал и может быстро исправить. А не в QA отдел и уж тем более не в Support.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: О каких еще ошибках?
От: Трурль  
Дата: 12.11.04 06:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Лучше по делу чего уного сказал бы.

Так все что по делу игнорируется.
Замечу, однако, что закрывать файлы в Обероне нет необходимости.
Re[12]: О каких еще ошибках?
От: Клапауций Ниоткуда  
Дата: 12.11.04 07:25
Оценка:
Здравствуйте, Трурль, Вы писали:

VD>>Лучше по делу чего уного сказал бы.

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

Нутко, подробнее пжалста. Почему не нужно ?
А я попробую заглючить это дело....
Re[10]: О каких еще ошибках?
От: Трурль  
Дата: 12.11.04 07:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>
VD>        catch (IndexOutOfRangeException)
VD>        { // Суда прийдем если args не содержит аргументов
VD>            Console.WriteLine("Enter path to file, lease.");
VD>        }
VD>

Обратите внимание на отсутствие логической связи между IndexOutOfRangeException и
"если args не содержит аргументов".
VD>
VD>        catch (Exception ex)
VD>        { // А сюда в случае любой ошибки. Так что если файла нет или еще что, 
VD>            // то незабудем сказать об этом пользователю.
VD>            Console.WriteLine(ex.Message);
VD>        }
VD>

Если файла нет или еще что, то система сама скажет об этом пользователю.
Re[13]: О каких еще ошибках?
От: Трурль  
Дата: 12.11.04 07:39
Оценка: :)
Здравствуйте, Клапауций, Вы писали:

Т>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.


К>Нутко, подробнее пжалста. Почему не нужно ?

К>А я попробую заглючить это дело....
Потому что они закрываются автоматически.
Re[14]: О каких еще ошибках?
От: Клапауций Ниоткуда  
Дата: 12.11.04 07:50
Оценка: :)
Здравствуйте, Трурль, Вы писали:

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


Т>>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.


К>>Нутко, подробнее пжалста. Почему не нужно ?

К>>А я попробую заглючить это дело....
Т>Потому что они закрываются автоматически.

Детерминированный сборщик мусора ?
Re[6]: О каких еще ошибках?
От: FR  
Дата: 12.11.04 09:56
Оценка: +3 :))
Здравствуйте, Сергей Губанов, Вы писали:


СГ>Естественно, на 0 не делил, я так делал: IF f > EPSILON THEN a := b/f; ...


То есть на отрицательные числа делить нельзя?
Что то не верится мне что ты, как недавно утверждал можешь писать безошибочный код
... << RSDN@Home 1.1.3 stable >>
Re[12]: О каких еще ошибках?
От: Sergey J. A. Беларусь  
Дата: 12.11.04 10:01
Оценка: 7 (2) +1
Здравствуйте, Трурль, Вы писали:

VD>>Лучше по делу чего уного сказал бы.

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

Ужасть какая. Вот вам простейшая программа:
MODULE A11;

  IMPORT StdLog, Files; 

  PROCEDURE AddSymbol();
  VAR  locator: Files.Locator; file: Files.File; writter: Files.Writer;
  BEGIN
    locator := Files.dir.This("C:\");
    file := Files.dir.Old(locator, "New.txt", FALSE);
    writter := file.NewWriter(NIL);
    writter.WriteByte(33);
  END AddSymbol;

  PROCEDURE T*();
  BEGIN
        StdLog.String("Cool Program started !");
        StdLog.Ln();
        AddSymbol();
  END T;

END A11.


Я не закрыл файл.

Результаты:
После первого запуска файл остался залоченным и в винде его открыть не удаётся.
Второй запуск выбрасывает исключение.

З.Ы. А исключения в BlackBox что нельзя обработать ??? Я сколько не искал — ничего такого не нашёл....
Я — свихнувшееся сознание Джо.
Re[7]: О каких еще ошибках?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:06
Оценка: +2 :))
Здравствуйте, FR, Вы писали:

FR>То есть на отрицательные числа делить нельзя?

FR>Что то не верится мне что ты, как недавно утверждал можешь писать безошибочный код
Ну, в теории — можно. В общем, это по-прежнему доказывает, что Оберон представляет собой типичный случай решения для сферического коня в вакууме. И собственно, все его сравнения с реальными методиками суть попытки доказать что его конь круглее, а вакуум — чище.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: О каких еще ошибках?
От: Трурль  
Дата: 12.11.04 11:08
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

SJA>Ужасть какая. Вот вам простейшая программа:

[]
SJA>Я не закрыл файл.

SJA>Результаты:

SJA>После первого запуска файл остался залоченным и в винде его открыть не удаётся.
SJA>Второй запуск выбрасывает исключение.

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

SJA>З.Ы. А исключения в BlackBox что нельзя обработать ??? Я сколько не искал — ничего такого не нашёл....


В BlackBox нельзя.
Re[14]: О каких еще ошибках?
От: Sergey J. A. Беларусь  
Дата: 12.11.04 11:20
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Я имел ввиду обычный Оберон, там файлы не блокируются.

Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
Или есть там какие-то подпорки и костыли ?
Я — свихнувшееся сознание Джо.
Re[11]: Есть ли плюсы у Оберона?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 11:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ух как зашибись. То есть опять — устойчивость системы гарантируется через test coverage и прочие пироги; т.е. путем геморроя. Намекну, что в С++, С# 2.0 и Java 1.5 в случае, если статический тип не CorrectPtr, то компиляция будет автоматически остановлена и сообщение об ошибке попадет сразу тому, кто ее сделал и может быстро исправить. А не в QA отдел и уж тем более не в Support.



Естественно, если процедура написана так: PROCEDURE f(p: CorrectPtr); то скопилировать модуль можно будет только если статический тип аргумента будет CorrectPtr.

Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);
Re[15]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 11:41
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

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


Т>>Я имел ввиду обычный Оберон, там файлы не блокируются.

SJA>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>Или есть там какие-то подпорки и костыли ?

Да нет, Вы не правильно поняли. ОС Оберон вся целиком является объектно ориентированной и вся целиком обслуживается одним единственным сборщиком мусора — там, грубо говоря, никто из пользователей не может отличить открытый файл от закрытого. Он просто обращается к файлмэнеджеру, а тот ему возвращает запрошенный файл, но сколько еще других пользователей сейчас работают с этим файлом Вы не знаете, поэтому и закрывать файл не надо. А BlackBox ограничен тем, что вынужден обращаться к файлам через Windows со всеми вытекающими...
Re[16]: О каких еще ошибках?
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 11:44
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

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


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


Т>>>Я имел ввиду обычный Оберон, там файлы не блокируются.

SJA>>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>>Или есть там какие-то подпорки и костыли ?

СГ>Да нет, Вы не правильно поняли. ОС Оберон вся целиком является объектно ориентированной и вся целиком обслуживается одним единственным сборщиком мусора — там, грубо говоря, никто из пользователей не может отличить открытый файл от закрытого. Он просто обращается к файлмэнеджеру, а тот ему возвращает запрошенный файл, но сколько еще других пользователей сейчас работают с этим файлом Вы не знаете, поэтому и закрывать файл не надо. А BlackBox ограничен тем, что вынужден обращаться к файлам через Windows со всеми вытекающими...


Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!
Re[12]: Есть ли плюсы у Оберона?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:47
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);
Однако, ваши обобщенные контейнеры почему-то в рантайме падают на всем, кроме CorrectPtr. Какая-то хреновая обобщенность получается.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: О каких еще ошибках?
От: Sergey J. A. Беларусь  
Дата: 12.11.04 11:52
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!


Именно это я и хотел сказать.
Я — свихнувшееся сознание Джо.
Re[12]: Есть ли плюсы у Оберона?
От: peterbes Россия  
Дата: 12.11.04 11:57
Оценка:
Здравствуйте, GlebZ, Вы писали:


GZ>Borland C++ 2.0 у меня лежал купленный практически с момента выхода(а это произошло еще до того как я пришел на ту работу в 1992). Затем был куплен Visual C++ 1.0 и я попрощался с OWL. Был еще Watcom, но когда он появился уже не помню (где-то 93 кажется).


А чем вам OWL не понравился? Мне интересно, спрашиваю потому что у вас была возможность сравнить первые версии MFC и OWL
Re[16]: О каких еще ошибках?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 11:57
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

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

Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 12.11.04 12:40
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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

СГ>>Однако, мы тут обсуждали обобщенные контейнеры работающие с типом ANYPTR, то есть когда процедура написана так: PROCEDURE f(p: ANYPTR);
S>Однако, ваши обобщенные контейнеры почему-то в рантайме падают на всем, кроме CorrectPtr. Какая-то хреновая обобщенность получается.

Так и должно быть, при использовании конструкции WITH. См. описание языка Оберон-2.
Я использовал IF p IS CorrectPtr THEN insert(p) END, в той реализации ничего не "падало". Но и с оператором WITH "падать" не будет, если Вы добавите ELSE.
Надо отметить, что способы "падения" системно зависимы. Можем первать работу программы и выдать диагностическое сообщение, можем выбросить исключение, а можем и проигнорировать, если считаем, что такое поведение допустимо.
Видимо, BlackBox в данной среде прерывает работу программы, что эквивалентно использованию ASSERT(p IS CorrectPtr).
Но в данном случае это и есть самое разумное поведение.
Прошу Вас вспомнить, в каком контексте все эти WITH p: CorrectPtr возникли.
Павел Кузнецов сказал, что требуется длительная отладка, чтобы выявить ситуации неправильного использования такого обобщенного контейнера.
Я усомнился в этом, сказав, что в Обероне не удастся обойти контроль типа, все такие ситуации будут выявлены.
Вы подтвердили мое утверждение: у Вас ни один указатель кроме CorrectPtr не принимается.

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

Хоар
Re[13]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 12.11.04 12:46
Оценка:
Здравствуйте, peterbes, Вы писали:

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



GZ>>Borland C++ 2.0 у меня лежал купленный практически с момента выхода(а это произошло еще до того как я пришел на ту работу в 1992). Затем был куплен Visual C++ 1.0 и я попрощался с OWL. Был еще Watcom, но когда он появился уже не помню (где-то 93 кажется).


P>А чем вам OWL не понравился? Мне интересно, спрашиваю потому что у вас была возможность сравнить первые версии MFC и OWL


1. Мне очень понравился AppWizard и ClassWizard. Не надо было лазить в хелп, чтобы узнать как точно пишется то или иное сообщение.
2. При обучении программированию на Windows, я сначала изучал Windows API для С. Когда мне я увидел первый MFC, который можно было назвать Wrapperом на WinAPI, он мне значительно больше понравился. Для начальной работы с MFC, было достаточно основных знаний WinAPI.
3. Насколько я помню, средств MFC 1.0 предоставлял несколько больше чем OWL (версию, к сожалению, не помню). Кажется впечатлило наличие Toolbar'ов.
4. Глючность OWL была больше чем у MFC. Глючность OWL + Глючность Windows + Глючность BC компилятора давала интересные эффекты. Компилятор Microsoft хоть и был значительно тормозней, но зато был более надежен.

Пункты отсортированы по важности.

С уважением, Gleb.
Re[14]: Есть ли плюсы у Оберона?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.11.04 12:57
Оценка:
Здравствуйте, AVC, Вы писали:
AVC>Прошу Вас вспомнить, в каком контексте все эти WITH p: CorrectPtr возникли.
Давайте вспомним.
AVC>Павел Кузнецов сказал, что требуется длительная отладка, чтобы выявить ситуации неправильного использования такого обобщенного контейнера.
Верно.
AVC>Я усомнился в этом, сказав, что в Обероне не удастся обойти контроль типа, все такие ситуации будут выявлены.
Нет там никакого контроля типа. Павел Кузнецов имел в виду проверку того, что мы достаем из контейнера то же, что и положили. В Обероне либо ты имеешь специализированный контейнер, куда можно положить только что-то одно и достать его же, либо абстрактный, куда можно положить все что угодно, а также и достать все что угодно.
И выявлено это будет только при даункасте достанного объекта. Во-первых, это в ран-тайме (что уже слишком поздно для исправления ошибки), во-вторых даже для рантайма это слишком поздно (т.к. теперь придется сканировать все исходники в поисках того, кто положил в контейнер каку).
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: О каких еще ошибках?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.04 13:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?


Чую курение над этой ситуацией приведет к тому что под сию замечательную ОС вместо классической ФС нужно будет подкладывать что то вроде WinFS.
... << RSDN@Home 1.1.4 beta 3 rev. 230>>
AVK Blog
Re[11]: Есть ли плюсы у Оберона?
От: folk Россия  
Дата: 12.11.04 13:22
Оценка:
Sergey J. A.:

> ПК>Попробуй VC 7.1 + whole program optimization.

>
> Тэкс. Похоже для sort он не делает слияние, но методы самого вектора он мержит:
>
> #include <cstdio>
> #include <vector>
> #include <algorithm>
> 
> using namespace std;
> 
> int main()
> {
>  vector<int> vi(100);
>  vector<void *> vs(100);
> 
>  __asm {int 3}
> 
>  vi.size();   // Одна ф-ия
>  vs.size();
> 
>  vi.push_back(0x666); // Одна ф-ия
>  vs.push_back((void *)0x666);
> 
>  sort(vi.begin(), vi.end()); // Разные
>  sort(vs.begin(), vs.end());
> 
>  return 0;
> }
>


Оно и понятно. Сортировка подразумевает сравнение, и было бы странным ожидать одинакового кода для сравнения указателей и знаковых целых. Скорее повезет с unsigned int.
Posted via RSDN NNTP Server 1.9 gamma
На самом деле, люди не читают газеты, они принимают их каждое утро, так же как ванну. ©Маршалл Мак-Льюэн
Re[15]: О каких еще ошибках?
От: AVC Россия  
Дата: 12.11.04 13:31
Оценка: :)
Здравствуйте, Sergey J. A., Вы писали:

Т>>Я имел ввиду обычный Оберон, там файлы не блокируются.

SJA>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>Или есть там какие-то подпорки и костыли ?

Наверное, удобно писать операционные системы на языке, который сам уже выполняет все функции операционных систем?
Интересно, Вы сами можете привести пример языка, который открывает файлы (да еще и "эксклюзивно") в обход самой операционной системы?
Мне кажется, Вы запамятовали, что в Обероне (как и в большинстве других языков, включая Си++) работа с файлами в язык не встроена. Поддержка работы с файлами осуществляется на уровне системных компонентов (того же модуля Files, например).
Так что Оберон тут ни при чем. Проблема где-то в "переходнике" между BlackBox и Windows.

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

Хоар
Re[17]: О каких еще ошибках?
От: Трурль  
Дата: 12.11.04 13:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?

Ну в ОС Оберон (тфу, чуть опять не написал "в Обероне", угораздило же Вирта назвать ОС и язык одинаково) этой проблемы не существует, потому как однозадачная она. А бутылку я еще толком не смотрел.
Re[18]: О каких еще ошибках?
От: Курилка Россия http://kirya.narod.ru/
Дата: 12.11.04 13:51
Оценка: +2
Здравствуйте, Трурль, Вы писали:

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


S>>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?

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

Каайф, однозадачность — это как раз то, что народу и надо
Re[15]: О каких еще ошибках?
От: Кодт Россия  
Дата: 12.11.04 13:58
Оценка:
Здравствуйте, Клапауций, Вы писали:

Т>>>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.


К>>>Нутко, подробнее пжалста. Почему не нужно ?

К>>>А я попробую заглючить это дело....
Т>>Потому что они закрываются автоматически.

К>Детерминированный сборщик мусора ?


Во-во.
Открыли файл на монопольную запись, поработали. Обнулили переменную, в которой хранится хэндл.
Сразу же открыли файл на монопольное чтение... во всяком случае, попытались...
Перекуём баги на фичи!
Re[16]: О каких еще ошибках?
От: Sergey J. A. Беларусь  
Дата: 12.11.04 14:04
Оценка:
Здравствуйте, AVC, Вы писали:

Т>>>Я имел ввиду обычный Оберон, там файлы не блокируются.

SJA>>Да... Наверное удобно писать операционные системы на языке, который на может открыть файл эксклюзивно.....
SJA>>Или есть там какие-то подпорки и костыли ?

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

AVC>Интересно, Вы сами можете привести пример языка, который открывает файлы (да еще и "эксклюзивно") в обход самой операционной системы?
AVC>Мне кажется, Вы запамятовали, что в Обероне (как и в большинстве других языков, включая Си++) работа с файлами в язык не встроена.
Отнюдь. Я ничего не запамятовал. Кстати говоря, что значит

работа с файлами в язык не встроена

? Значит в стандарте языка не прописаны стандартные средства для работы с файлами ? Так почитайте стандарт С++ — узнаете много нового.

AVC> Поддержка работы с файлами осуществляется на уровне системных компонентов (того же модуля Files, например).

AVC>Так что Оберон тут ни при чем. Проблема где-то в "переходнике" между BlackBox и Windows.

Да ну ? Трурль заявил, что Оберон такая система, где закрывать файлы не нужно. Затем поправился и сказал, "Я имел ввиду обычный Оберон, там файлы не блокируются". Так всё же — файлы нельзя блокировать или нельзя незакрывать ?
Я — свихнувшееся сознание Джо.
Re[12]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 14:46
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Так все что по делу игнорируется.

Т>Замечу, однако, что закрывать файлы в Обероне нет необходимости.

Извини, но это выглядит чушью. Файлы открываются в ОС и никаких средств автоматического закрытия кроме по средством сборки мусора я в Обероне не вижу. Стало быть файлы останутся заблокированными до сборки мусора или завершения приложения.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 14:46
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Я имел ввиду обычный Оберон, там файлы не блокируются.


Что такое "обычный Оберон"? И как он умудряется разделять файлы без блокировок? А так же читать их без открытия в ОС?

В любом случае язык претендующий на

Т> Как-то не учел, что здесь битва вокруг ящика идет. В блекбоксе по сути то же самое, при использовании разделяемого доступа. А если открыть файл для монопольного доступа, то надо, конечно закрывать или, по крайней мере, не отрывать его же второй раз.


"А если" тут не катит. Всегда есть "а если" и эти если нужно решать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 14:46
Оценка:
Здравствуйте, Sergey J. A., Вы писали:

К>>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!


SJA>Именно это я и хотел сказать.


Думаю — это был стеб.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 14:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пардон, а как разруливаются проблемы согласованности? Ну вот если у нас два активных объекта открыли один и тот же файл и пишут в него — один пишет "1111111111111...", а другой — "22222222222222...". Что будет в результирующем файле?


Да и вообще интересно как с инародными и раделяемыми ресурсами. Ну, например с теми же TCP-соеденениями с другими серверами.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 15:37
Оценка: :)
Здравствуйте, VladD2, Вы писали:

К>>> супер, такие ОС суть светлое будущее!


Задумайтесь пожалуйста над вопросом: Что такое ФАЙЛ в объектно ориентированной операционной системе?
Файл — это персистентный объект, а файлменеджер (или файловая система) — это объектно ориентированная СУБД, в которой храняться такие персистентные объекты. Если на всю систему есть всего один единственный сборщик мусора, то пользователи этого персистентного объекта не должны сохранять его самостоятельно — это сделает за них ОО-СУБД. На сколько я знаю, в следующей версии MS Windows будет примерно такая "файловая" система. Так что такое светлое будущее, можно сказать, неотвратимо повсеместно наступит как только выйдет эта самая виндос, а пока аналоги этого есть в оберон-системах.
Re[15]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 15:41
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что такое "обычный Оберон"? И как он умудряется разделять файлы без блокировок? А так же читать их без открытия в ОС?


"обычный Оберон" — это такая операционная система Native Oberon, а не язык.
Re[13]: О каких еще ошибках?
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.11.04 15:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Т>>Так все что по делу игнорируется.

Т>>Замечу, однако, что закрывать файлы в Обероне нет необходимости.

VD>Извини, но это выглядит чушью. Файлы открываются в ОС и никаких средств автоматического закрытия кроме по средством сборки мусора я в Обероне не вижу. Стало быть файлы останутся заблокированными до сборки мусора или завершения приложения.


"Оберон", в данном контексте, обозначало не язык, а операционку, просто и язык и операционка носят одинаковое название.
Re[19]: О каких еще ошибках?
От: Sergey J. A. Беларусь  
Дата: 12.11.04 16:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sergey J. A., Вы писали:


К>>>Ага, значит залочить файл в ОС Оберон мы изначально не сможем — супер, такие ОС суть светлое будущее!


SJA>>Именно это я и хотел сказать.


VD>Думаю — это был стеб.


Что именно было стёб ?
Я хотел сказать, что если

такие ОС суть светлое будущее

было сказано в виде сарказма, то я именно это и хотел сказать.
Я — свихнувшееся сознание Джо.
Re[11]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 16:30
Оценка:
Здравствуйте, Трурль, Вы писали:

VD>>
VD>>        catch (IndexOutOfRangeException)
VD>>        { // Суда прийдем если args не содержит аргументов
VD>>            Console.WriteLine("Enter path to file, lease.");
VD>>        }
VD>>

Т>Обратите внимание на отсутствие логической связи между IndexOutOfRangeException и
Т>"если args не содержит аргументов".

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

VD>>
VD>>        catch (Exception ex)
VD>>        { // А сюда в случае любой ошибки. Так что если файла нет или еще что, 
VD>>            // то незабудем сказать об этом пользователю.
VD>>            Console.WriteLine(ex.Message);
VD>>        }
VD>>

Т>Если файла нет или еще что, то система сама скажет об этом пользователю.

Система сама ничего умного сазать к сожалению не всилах. ИИ еще не изобретен. По идее нужно было бы делать проверку количества аргументов переданных приложению и если что возбуждать исключение с осмысленным сообщением.

Однако исключения поймают и непредвиденную ошибку. Просто сообщение дудет не стольк внятным. Но система останется на плаву. А вот без исключений будет кирдык всему приложению (системе).
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 16:30
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Чую курение над этой ситуацией приведет к тому что под сию замечательную ОС вместо классической ФС нужно будет подкладывать что то вроде WinFS.


Интересно как у объектов WinFS с IDisposable?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 16:30
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>Каайф, однозадачность — это как раз то, что народу и надо


Скажем проще — верх прогресса. Ради этого нужно было выбросить из языка остатки разумного...
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 16:30
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Мне кажется, Вы запамятовали, что в Обероне (как и в большинстве других языков, включая Си++) работа с файлами в язык не встроена. Поддержка работы с файлами осуществляется на уровне системных компонентов (того же модуля Files, например).


Речь о том, что язык настолько примитивен, что вообще не имеет удобных средств контроля внешних ресуросов. Все нужно делать на морях if-ов. Т.е. как в старом добром С времен Керникана & Ричи.

С тех времен прошло 30 лет. И все языки используемые на практике давно обзавились средствами контроля ресурстов. В Шарпе, например, это конструкции:
try
{
}
catch
{
}
finally
{
}

для отлова ошибок и защиты ресурсов.
А так же:
using (ResourceHolderType var = new ResourceHolderType())
{
    // использование ресурса
} // автоматическое освобождение ресусрвов.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: О каких еще ошибках?
От: Кодт Россия  
Дата: 12.11.04 17:26
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Задумайтесь пожалуйста над вопросом: Что такое ФАЙЛ в объектно ориентированной операционной системе?

СГ>Файл — это персистентный объект, а файлменеджер (или файловая система) — это объектно ориентированная СУБД, в которой храняться такие персистентные объекты. Если на всю систему есть всего один единственный сборщик мусора, то пользователи этого персистентного объекта не должны сохранять его самостоятельно — это сделает за них ОО-СУБД. На сколько я знаю, в следующей версии MS Windows будет примерно такая "файловая" система. Так что такое светлое будущее, можно сказать, неотвратимо повсеместно наступит как только выйдет эта самая виндос, а пока аналоги этого есть в оберон-системах.

Замечательно, раз мы заговорили о СУБД.
Не закрывать файл — это то же самое, что не завершать транзакцию. Начали, поковырялись в базе и... и пожалуй, всё (© Мексиканские Негодяи).
После какого количества таких упражнений сервер нас пошлёт? Скольких клиентов сервер пошлёт до того, как пошлёт нас?

Я уже говорил как-то, что идея сборки мусора, реализованная только на уровне примитивов ОС — однозначно, недостаточна.
Логическую уборку всё равно должен совершать разработчик: завершать транзакции, отпускать монопольно занятые физические устройства (например, ком-порт).
Перекуём баги на фичи!
Re[14]: О каких еще ошибках?
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.11.04 17:43
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>"Оберон", в данном контексте, обозначало не язык, а операционку, просто и язык и операционка носят одинаковое название.


Фиговое оправдание. Тут все же обсуждается язык. Более того в школы ты БлэкБокс толкаеш. Так что не нужно переключаться.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Есть ли плюсы у Оберона?
От: Kh_Oleg  
Дата: 15.11.04 08:25
Оценка:
Здравствуйте, VladD2, Вы писали:

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


K_O>>Говоря по-русски: чтобы предотвратить разбухание кода вводится частичная специализация для того случая, когда std::vector специализируется указателем. Оптимизация, так сказать.


VD>СтлПорт рассчитан на компиляцию на самых разных компиляторах. Для VC 7+ и Intel C++ подобная фигня не нужна.

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

Ну и в-третьих. Разговор начался с разбухания кода и утверждения, что линкер может это мержить. То, что линкер умный — это хорошо. Но беда в том, что он тормозной! И под "разбуханием кода" не всегда понимается размер конечного экзешника (к счастью, прошли времена 640Kb ОЗУ), а размер объектников, которые достаются линкеру в наследство от компилятора. Из-за этого "умному" линкеру предстоит масса дурной работы, что существенно замедляет время ликновки.

А в-четвретых, не всем выпала такая удача писать только под винду. Приходится и на Иксах работать. Размер экзешников на винде и на солярке, собранных из одних и тех же исходников отличается в четыре раза! Так что, разбухание кода — не миф, далеко не миф.
Re[17]: О каких еще ошибках?
От: Трурль  
Дата: 15.11.04 13:05
Оценка: :)
Здравствуйте, Sergey J. A., Вы писали:

SJA>Да ну ? Трурль заявил, что Оберон такая система, где закрывать файлы не нужно. Затем поправился и сказал, "Я имел ввиду обычный Оберон, там файлы не блокируются". Так всё же — файлы нельзя блокировать или нельзя незакрывать ?

В Обероне нельзя блокировать, а в Блэкбоксе нельзя незакрывать заблокированные.
Re: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 15.11.04 17:35
Оценка: 78 (3)
Прошу прощения за отсутствие: проблемы с выходом в Интернет.
Много уже «напостили», всем ответить уже вряд ли удастся, да, может быть, уже и нет необходимости.
Поэтому попытаюсь подвести итог форума, как он мне видится.
Цель, которую я себе ставил (обсудить принципы построения Оберон-систем: раздельная компиляция, отказ от понятия монолитной (stand-alone) программы, расширяемость системы, использование единого адресного пространства и «сборщика мусора», жесткий контроль типа), я выполнить не смог. Тому есть две причины: собственная слабая «подкованность» в Обероне, а также нетерпимость критиков.

Надо отметить, что критики действительно нашли несколько сомнительных мест в Обероне.
Павел Кузнецов указал, что нет возможности использовать статический контроль типа в контейнерах.
Кодт обратил внимание на отсутствие стандарта Оберона.
Это все, увы, верно.

Была и другая критика. Говорили, что нет исключений, многопоточности, нельзя блокировать файлы. Эта критика тоже важна, но менее значима, т.к. все это легко реализуется в Оберон?системе в случае необходимости, и есть такие реализации. Для этого не требуется расширения базового языка. Поэтому сейчас не буду на этом сосредотачиваться, отмечу только, что примерные способы реализации уже были приведены в издававшихся у нас книгах Вирта «Программирование на языке Модула-2» и «Алгоритмы и структуры данных».

Поэтому сейчас хочу обсудить существенную критику и пояснить, что же меня заинтересовало в Обероне.
Действительно, я не знаю в Обероне средства, аналогичного template Си++, и это «не есть хорошо». Такая же проблема была (раньше?) и в Java. (Что, впрочем, неудивительно, т.к. перенеслась она туда прямиком из Оберона.) Я даже на досуге попытался придумать такое минимальное уточнение языка, чтобы позволить компилятору отслеживать помещение в контейнеры «нежелательных» объектов. Но никто все же мне не объяснил, а что такого уж «страшного» может случиться, почему потребуется «длительная отладка»? Ведь в Обероне невозможно получить доступ к данным, несанкционированный системой контроля типов. (Попробуйте!)
Что касается отсутствия стандарта Оберона, то это просто беда какая-то с виртовскими языками… Стандарт на Паскаль был поспешным, на Модулу-2 – запоздал, а на Оберон – его и вовсе нет. И ведь что интересно, встречались разработчики компиляторов Оберона-2 еще в 1993 году, выработали «дубовые требования» (Oakwood guidelines), а где стандарт? Возможно, в языке есть какие?то не решаемые проблемы, но до этого мы на форуме не добрались, т.к. критика была настроена бескомпромиссно и выражалась, в основном, в виде вопросов, а как на Обероне сделать xxx, готовая принять только решения проблем, «изоморфные» их любимым языкам. Но если языки полностью «изоморфны», зачем их два?

Теперь о том, что меня привлекло в Обероне. Так вышло, что в последнее время мне приходится делать системы программирования для «самопальных» процессоров нашей «фирмы». И требования у меня получаются во многом противоположными критикам: компилятор должен быть как можно меньше и надежнее, отладка программ должна отнимать как можно меньше времени и сил, самое дорогостоящее – это память.
И вот я увидел, что Оберон мог быть стать хорошим решением для данного случая. Кроме того (это уже личное), Оберон (как техническое решение) очень красив.
Смотрите сами компилятор, написанный Виртом, занимал всего 45K и работал как часы.
А главное – надежность.
Ведь что самое опасное в языках вроде Си и Си++? Как раз то, что является очень красивым синтаксическим решением: адресная арифметика (т.е. то, как в Си используется указатель).
Указатель в Си может указывать не только на объект кучи, а куда угодно. Следовательно, «сборщик мусора» вряд ли удастся реализовать без «больших потрясений».
Инициализация указателя безопасным значением не гарантируется компилятором.
Указатель может указывать на элементы массива, что затрудняет контроль индексов.
Явное приведение типов указателей в Си очень распространенно и может служить источником самых непредсказуемых «глюков».
Только часть всех «глюков» может быть обнаружена операционной системой, ведь указатель может быть неправильно использован и в пределах адресного пространства процесса.
Короче, меня в Си не устраивает концепция указателя.
Вспоминается один мой знакомый программист. Он начинал программировать на Паскале и никак не мог понять, что же такое «указатель». А когда перешел на Си, то обрадовался: да ведь это просто адрес памяти, ничего больше! Как вы думаете, надо ли этому радоваться?

Что же касается сторонников языков: Java и C#, то им вообще «пинать» Оберон – грех. Ведь с начала 1994 года Sun все время консультировалась у ETH, приобрела лицензию на виртовский Оберон, упросила Франца читать лекции. Ведь многие свойства ваших любимых языков перенесены из Оберона. Как же можно после этого так злобствовать?

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

Хоар
Re[2]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 15.11.04 18:01
Оценка: +2
Здравствуйте, AVC, Вы писали:

AVC>Надо отметить, что критики действительно нашли несколько сомнительных мест в Обероне.

AVC>Павел Кузнецов указал, что нет возможности использовать статический контроль типа в контейнерах.
AVC>Кодт обратил внимание на отсутствие стандарта Оберона.
AVC>Это все, увы, верно.

AVC>Была и другая критика. Говорили, что нет исключений, многопоточности, нельзя блокировать файлы. Эта критика тоже важна, но менее значима, т.к. все это легко реализуется в Оберон?системе в случае необходимости, и есть такие реализации. Для этого не требуется расширения базового языка. Поэтому сейчас не буду на этом сосредотачиваться, отмечу только, что примерные способы реализации уже были приведены в издававшихся у нас книгах Вирта «Программирование на языке Модула-2» и «Алгоритмы и структуры данных».

Посмотрел описание Zoonon, есть там исключения, синхронизация. здесь

AVC>Что же касается сторонников языков: Java и C#, то им вообще «пинать» Оберон – грех. Ведь с начала 1994 года Sun все время консультировалась у ETH, приобрела лицензию на виртовский Оберон, упросила Франца читать лекции. Ведь многие свойства ваших любимых языков перенесены из Оберона. Как же можно после этого так злобствовать?

Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы. Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.

С уважением, Gleb.
Re[3]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 16.11.04 14:27
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы.


А если бы еще в 80-х, когда он появился?

GZ>Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.


Я, в основном, с этой "кочки" (ограничения имеют значение) и смотрю.
Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.
Что же касается Zonnon, то, по первому впечатлению, просто в язык добавили то, что раньше опционально реализовывалось в модулях Оберон-систем.
И язык сразу стал "современным", "не хуже, чем у людей".
Но, imho, для решения задач, подобных моим, "базовый" Оберон проще и перспективнее.

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

Хоар
Re[3]: Есть ли плюсы у Оберона?
От: Трурль  
Дата: 16.11.04 14:51
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Если бы я встретил этот язык в 1994 году, я бы наверно ему подивился бы. Но сейчас, на примере Zoonan, мне кажется что Оберон языки в роли догоняющего. С 90-х годов появилось достаточно много более современных языков. Правда для большинство из них в 45кБ никак не уместятся. Для процессоров, с такими ограничениями, возможно и нужны такие старые языки как С, Forth или (может быть) Oberon.


Споры между сторонниками "больших" и "маленьких" языков ведутся с давних пор. И добавление новых конструкций одни встречают с восторгом, а другие с раздражением. PL/1 одни называли "окончательным решением всех проблем", а другие "рожденственской ёлкой, на которой каждый может себе найти пряник или хлопушку".
Кстати, многим оберонщикам Zoonon решительно не нравится.
Re[4]: Есть ли плюсы у Оберона?
От: GlebZ Россия  
Дата: 16.11.04 16:02
Оценка:
Здравствуйте, AVC, Вы писали:

AVC>Я, в основном, с этой "кочки" (ограничения имеют значение) и смотрю.

AVC>Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.
Насчет того что проще, еще вопрос. Давным давно обсуждался вопрос, что такое С: высокоуровневый язык или очень продвинутый оптимизированный макроассемблер. Это было еще до С++. Если убрать реализацию стандартных библиотек, то простота компилятора еще вопрос. Ну а про надежность, абсолютно согласен на 200%.
AVC>Что же касается Zonnon, то, по первому впечатлению, просто в язык добавили то, что раньше опционально реализовывалось в модулях Оберон-систем.
AVC>И язык сразу стал "современным", "не хуже, чем у людей".
У меня простым просмотром описаний, тоже сложилось такое зрение. Если многим Оберонщикам не нравится Zoonan, прекрасно это понимаю. Основная причуда и идеология Oberona было конечно понятие модуля. В zoonan все эти средства расплываются и подменяются. Язык стал очень походить на остальные. Людям такой отход от идеалогии должен быть действительно обиден.
AVC>Но, imho, для решения задач, подобных моим, "базовый" Оберон проще и перспективнее.
Реализация сборки мусора при таком маленьком компайлере, по моему вещь очень продвинутая. К сожалению, после определенного момента, реализации языков перестали обращать внимание на подобную компактность. Правда, кажется, были достаточно компактные реализации Java.

С уважением, Gleb.
Re[5]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 18.11.04 10:02
Оценка: 1 (1)
Здравствуйте, GlebZ, Вы писали:

AVC>>Компилятор Оберона проще компилятора Си, а возможности и надежность значительно выше.

GZ>Насчет того что проще, еще вопрос. Давным давно обсуждался вопрос, что такое С: высокоуровневый язык или очень продвинутый оптимизированный макроассемблер. Это было еще до С++. Если убрать реализацию стандартных библиотек, то простота компилятора еще вопрос. Ну а про надежность, абсолютно согласен на 200%.

Сейчас я в целом согласен с Виртом: Си не является высокоуровневым языком (по-моему, Си на это и не претендовал).
Я допускаю, что во многом моя точка зрения определяется весьма специфическими потребностями (делать надежные автономные программные системы минимальными силами). Здесь Оберон, imho, не оставляет Си никаких шансов. Сейчас, как только кончится "запарка" с тестированием процессора, я собираюсь представить по этому поводу доклад нашему руководству, с рассмотрением плюсов и минусов разных подходов. С разработчиками процессора я уже разговаривал. Они проявили значительный интерес к принципам Оберона.
Что же касается библиотек, то ведь опять же реализовывать их приходится мне самому, что только увеличивает объем моей работы. В случае же с Обероном мы сможем наращивать систему коллективными усилиями (программируя уже на самом Обероне), вводя новые модули по мере необходимости.
Ну и, само собой, — надежность!

GZ>У меня простым просмотром описаний, тоже сложилось такое зрение. Если многим Оберонщикам не нравится Zoonan, прекрасно это понимаю. Основная причуда и идеология Oberona было конечно понятие модуля. В zoonan все эти средства расплываются и подменяются. Язык стал очень походить на остальные. Людям такой отход от идеологии должен быть действительно обиден.


Лично мне нравится Оберон-2, как он сформулирован авторами языка — Виртом и Мессенбоком (кстати, второй из них создал Coco/R; вопреки некоторым утверждениям, на C# его просто заимствовали), а также стандартом de facto Оберона-2 — Oakwood guidelines.
Оберон-2 изучить очень легко. (Я без всяких проблем написал несколько программ, пока еще учебных. Причем некоторые — в первый же день знакомства с Обероном.)
Компилятор Оберона-2 можно создать в одиночку. А компилятор Zonnan?

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


И это жаль!
Я не против существования "больших" языков, но обязательно должны быть и альтернативные "маленькие" языки.

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

Хоар
Re[3]: Комментарий по Zonnon
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 18.11.04 10:48
Оценка: -2 :)
Здравствуйте, GlebZ, Вы писали:

GZ>Посмотрел описание Zoonon, есть там исключения, синхронизация. здесь


1) Как только его не обзывали Zoonon, Zoonan..., а правильно Zonnon.
2) Официальная страница у него вот такая: http://www.zonnon.ethz.ch/ (а не блюботлевая)
3) Разработка Zonnon осуществляется на деньги Microsoft, а, как известно, кто платит, тот и заказывает музыку. От оригинального оберона, в Zonnon разьве только правильный (единственно верный) синтаксис и остался. На сколько лично я понял, нигде кроме как под .NET этого Zonnon больше не будет (впрочем это же справедливо и для C#).
Re[6]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 18.11.04 14:07
Оценка: +1
AVC,

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


Было бы очень интересно подобный доклад почитать.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[7]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 18.11.04 14:37
Оценка: 1 (1)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Было бы очень интересно подобный доклад почитать.


Если дело действительно дойдет до доклада (я на это надеюсь), то тезисы в краткой форме могу выложить и на форуме.
Упор будет сделан на свойства Оберон-систем и их сопоставление со свойствами других систем.
Если кратко: type safety против memory protection.

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

Хоар
Re[8]: Есть ли плюсы у Оберона?
От: Павел Кузнецов  
Дата: 18.11.04 14:45
Оценка:
AVC,

> ПК> Было бы очень интересно подобный доклад почитать.


> Если дело действительно дойдет до доклада (я на это надеюсь), то тезисы в краткой форме могу выложить и на форуме.


Я бы с удовольствием почитал.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[9]: Есть ли плюсы у Оберона?
От: AVC Россия  
Дата: 18.11.04 14:49
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Я бы с удовольствием почитал.


OK.
Только это будет после тестирования.

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

Хоар
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.