спокойно принимается компилятором Си (gcc), но не компилятором Си++ (g++).
Компилятор же Microsoft не принял этот текст ни как "сишный", ни как "си++ный".
Загадочна совместимость что между языками Си и Си++, что между компиляторами...
ПК>В общем, к гадалке не ходи: есть встроенные массивы массивов в C++, нет встроенных массивов массивов в C++ — науке не известно Даже если принять точку зрения, что встроенные массивы массивов в C++ есть, то надо будет сразу делать кучу оговорок, что массивы в языках C и C++ вообще на положении бедных родственников (not a first class citizens). Что мне лично при использовании данных языков не нравится, но вероятность исправления данной ситуации, пожалуй, устремлена к 0 из-за соображений обратной совместимости. ПК>С другой стороны, имхо, верным будет и утверждение, что в C++ это компенсируется развитыми возможностями создания своих типов, по использованию, фактически, не отличающихся от встроенных.
"И ты прав. И ты прав."
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Privalov, Вы писали:
P>Те, кто меня учили, утверждали, что главная часть любого инструмента — голова его владельца. Лишний раз подтверждается их правота.
Т.е. если надо долбить стену...
Шутка.
P>Как утверждает здесь сам Страуструп, компилятор C++ реализован им самим. Думаю, что это достаточно серьезный проект.
Кажется, Страуструп создал Cfront.
Возможно, впоследствии написал компилятор для ранней версии Си++.
Но вряд ли Вы будете утверждать, что какой-нибудь из современных компиляторов Си++ написан лично Страуструпом.
Думаю, полезно было бы, если бы автор языка самолично писал (и переписывал, если в язык внесены изменения) его компилятор.
Уверен, что качество языков повысилось бы.
P>Вирт стремится создать идеальную систему. Здесь можно прочитать о проектах, над которыми он работал. Немногие из них дошли до нас в первозданном виде. (В тот год, когда я стал студентом, обучение программированию стало вестись на базе Фортрана, до этого оно велось на базе алгола. Не думаю, что это наш курс повлиял).
Вирт стремится создать надежный (а не идеальный) язык программирования.
Одна из причин такого его желания изложена здесь: http://www.inr.ac.ru/~info21/info/wirth_avia.htm
Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п.
Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором.
Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.
P>Страуструп, напротив, практик. Его место работы, можно сказать, КБ или отраслевой НИИ. Основная задача таких организаций — воплощение в жизнь теорий, создаваемых академиками. Где-то на этом форуме уже обсуждалась подобная тема.
Напротив?!
(Т.е. Вирт — не практик, что ли?)
Страуструп — практик?!
Ну, назовите что-нибудь, созданное Страуструпом, помимо Си++.
Да и тот давно уже создается огромным комитетом...
P>Работа Вирта дала материал для размышления многим, в том числе Страуструпу. Однако, прагматизм последнего (вольный или невольный), несомненно, сыграл свою роль в том, что C++ распространен гораздо шире, чем любой из проектов Вирта.
Да не прагматизм (который у Страуструпа, конечно, вольный; свои взгляды он изланает в книге об "Дизайн и эволюция Си++"), а поддержка Bell Labs.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Главное-то забыл спросить (давно собирался).
Когда-то (давно) Вы писали о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели.
Я тогда этот пост "проспал", а теперь немного жалею.
Можно ли все-таки сделать указатели в Си/Си++ надежными?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
> Главное-то забыл спросить (давно собирался). > Когда-то (давно) Вы писали о том, что можно попытаться сделать > "надежный" Си, по другому реализовав указатели. > Я тогда этот пост "проспал", а теперь немного жалею. > Можно ли все-таки сделать указатели в Си/Си++ надежными?
> Можно ли все-таки сделать указатели в Си/Си++ надежными?
Можно. Но, очевидно, они перестанут напрямую "ложиться" на аппаратные указатели. Стандарт такой вариант допускает, но практически в этом много проблем. Впрочем, думаю, можно извернуться, предоставив такие проверки, по крайней мере, в отладочном режиме.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Cyberax, Вы писали:
C>AVC пишет: >> Можно ли все-таки сделать указатели в Си/Си++ надежными? C>Да, можно. Есть здесь: http://manju.cs.berkeley.edu/cil/ C>Хотя придется отказаться от части функций языка.
Спасибо!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
>> о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели. Я тогда этот пост "проспал", а теперь немного жалею. ПК>Гм... Наверное, здесь: http://rsdn.ru/Forum/Message.aspx?mid=888051&only=1
Спасибо, именно этот пост я и пытался вспомнить.
Примерно такое решение я и предполагал.
Я помню о своем обещании выдать текст о сравнительной применимости Оберона (по крайней мере, в определенных пределах) по окончании отладки нашего процессора.
Однако, процесс разработки и отладки у нас затянулся, и только сейчас близится к завершению.
Иногда сам этот процесс подбрасывал мысли к дискуссии о языках. (Например, неявное приведение bool к float в Си++.)
В течении этого времени я собирал критику Оберона (и даже провоцировал ее несколько крайними суждениями о Си++ ).
На самом деле существенной критики не так уж и много.
Основная критика языка связана с отсутствием аналога шаблонов и дженериков.
Как я предполагаю, шаблонов в Обероне нет (хотя и есть во многих его расширениях) из-за раздельной компиляции и динамической загрузки.
Вы тогда упоминали дженерики в C# 2.0.
Но там требовалась JIT компиляция.
Как мне кажется, для Оберона вполне приемлем ограниченный вариант дженерика, не требующий дополнительной компиляции вовсе.
Расширение языка при этом требуется минимальное.
(Вирт, может быть, придумал бы способ сделать это вовсе не расширяя язык. )
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Возникает вопрос, по зачем тут втроенный ассемблер, если все что нужно можно написать на Oberon? Или это ран тайм языка? Очень похоже. Т.е. в основе все как и везде, машинный код и ассемблер, и без него никуда
2) Oberon язык компилируемый (если ошибся извините). Значит в скомпилированном модуле находятся машинные коды х86. Кто мешает мне вписать туда код
MOV BX,<левый адрес>
MOV [BX],<всякий мусор>
Проехались по чужой памяти, более того эта пара интсрукций не является привеллегированной и в общем случае нельзя сказать, она допустима или нет (т.е. на проверки кода перед исполнением особо рассчитывать не приходится). Просматривается широкий простор для создателей вирусов.
3) По поводу операционных систем. ОС — некое ПО предоставляющее сервисы, пользователю или другому ПО не важно, тогда чем простите вам ран-тайм языка отличается от простой ОС. Да ничем.
4) Вот теперь представьте, что ВЫ хотете написать программу, которая работает на голом железе (без всяких там ран-таймов), ничего не выйдет. Окажется что сначала рантайм спортировать надо — вот она ваша ОС, размер немного другой, суть та же. А на С (C++ немного сложнее) как делать нефиг, ПО для контроллеров так и пишут. Железку проинициализировал, стек настроил, вызвал код на С, далее ОС инициализим (если она вообще нужна), и поехали, тут вам и многопоточность, тут вам и мьютексы и состояние ожидания, и активные объекты если надо
5) А вы вообще про ОС реального времени слышали? Возмите код хоть одной из них, посмотрите.
P.S. Специально зарегистрировался чтобы ответить
СГ>Здравствуйте, Cyberax, Вы писали:
C>>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных C>>ОС. Еще рекомендую почитать про O(1) планировщики.
СГ>spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).
AVC>Как я предполагаю, шаблонов в Обероне нет (хотя и есть во многих его расширениях) из-за раздельной компиляции и динамической загрузки. AVC>Вы тогда упоминали дженерики в C# 2.0. AVC>Но там требовалась JIT компиляция.
Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).
Просто их можно легко использовать из MSIL кода так как они в отличие от шаблонов "Типизированы". То есть неопределенный тип должен поддерживать наложенные на него ограничения ввиде интерфейсов, делегатов итд.
Так, что по аналогии с dcu из них легко сгенерить код под определенный тип.
Если образно сравнивать шаблоны и дженерики то в первом случае это позднее связывание а дженерики раннее.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AVC, Вы писали:
AVC>Главное-то забыл спросить (давно собирался). AVC>Когда-то (давно) Вы писали о том, что можно попытаться сделать "надежный" Си, по другому реализовав указатели. AVC>Я тогда этот пост "проспал", а теперь немного жалею. AVC>Можно ли все-таки сделать указатели в Си/Си++ надежными?
Здравствуйте, Костя Ещенко, Вы писали:
AVC>>Можно ли все-таки сделать указатели в Си/Си++ надежными? КЕ>Например есть т.н. безопасный диалект C Cyclone http://www.research.att.com/projects/cyclone/ , там есть ссылки и на другие подобные проекты. Но лично мне оно не понравилось.
Спасибо!
Скачал, при первой возможности постараюсь вникнуть.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п. AVC>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором. AVC>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.
Здравствуйте, Serginio1, Вы писали:
AVC>>Но там требовалась JIT компиляция. S> Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).
Спасибо, я и правда почему-то в этот момент забыл, что в .NET все подвергается JIT.
А хотел я сказать, что Оберон (как язык в целом, а не только Оберон.NET) может использоваться и в условиях, не допускающих JIT-компиляцию в момент загрузки (хотя сама эта техника "докомпиляции" при загрузке, кажется, именно в Обероне и появилась: в OMI — Oberon Module Interchange — для переносимости модулей из одной среды в другую).
Возможно, поэтому дженерики и не входят в состав языка Оберон, что могут быть применены не везде. (Хотя до конца это мне неясно.)
Ущерб здесь не для функциональности Оберона, а для статического контроля типов, на что обращалось внимание.
Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
СГ>Здравствуйте, RailRoadMan, Вы писали:
RRM>>1) Идем на сайт BlueBottle, далее Download Current, далее AosSysSrc.zip, далее AosKernel.mod, смотрим
СГ>Спасибо за такой ответ. СГ>Кроме Вас еще никто не сподобился скачать BlueBottle и посмотреть на ее исходный код.
Ну я особо не вникал в код , интересно было посмотреть как там низкоуровневый аспекты реализованы, оказалось на асме (ну по другому никак). Только имхо, встроенный ассемблер — не очень удачное решение, проще отдельный ассемблер, переносить код на другие архитектуры лучше будет.
СГ>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос.
Вот этот вопрос принципиальный, если там все так просто с вирусами, то эту систему нельзя использовать там, где неквалифицированный (в хорошем смысле слова) пользователь запускает программы полученные на стороне. На атомной станции (вы писали, что там вроде оберон применяется) там понятно дело левых программ нет, их долго тестируют, проверяют и т.п. можно и на обероне писать. Кстати ПО для автомобильной электроники на С пишется, а в качетсве ОС там OSEK (www.osek-vdx.org), не атомная сканция конечно, но тоже критично.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Cyberax, Вы писали:
C>>RTFM про spinlock'и и мьютексы, а так же про их реализацию в современных C>>ОС. Еще рекомендую почитать про O(1) планировщики.
СГ>spinlock'и и мьютексы — это объекты операционной системы, а Вы попробуйте обойтись без объектов ОСи — средствами только самого языка программирования. Представьте себе что хотите написать программу которая должна работать на голом железе (точнее — в рантайм системе языка программирования).
С точки зрения embedded программирования для устройсвт с небольшой производительностью оберон плохо применим. Ему ран-тайм нужен в обязательном порядке (тлт можно без него? хотя сомнеаваюсь). А если на не нужны ни активный объекты, ни сборщики мусора (для большого количества встроенных приложения можно вообще статически данные выделять), то зачем платить памятью и производительностью за этот ран-тайм. А минимальной ядро для организации параллельных вычислений и синхронизации можно втиснуть в несколько сотен байт или пару килобайт
Здравствуйте, Дарней, Вы писали:
AVC>>Кроме языков и операционок Вирт проектировал компьютеры, писал САПР, встроенное ПО беспилотного вертолета (OLGA) и т.д. и т.п. AVC>>Все рассуждения об "академизме" Вирта высосаны из единственного факта, что он имел несчастье быть еще и профессором. AVC>>Если Вы не согласны, тогда сформулируйте, пожалуйста, в чем именно состоит академичность Вирта и в чем именно Страуструп практик.
Д>А где сейчас те языки, операционки и вертолеты?
По-моему об этом уже достаточно много говорили.
Видимо, подтекст такой, что сейчас это не используется?
Это не так.
Паскаль используется.
Модула-2 используется в космической промышленности (кстати, в том числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики.
Оберон-2 используется, например, в NASA.
Беспилотные вертолеты по-прежнему летают. (Кстати, OLGA означает Oberon language goes airborne.) Хотя эта сфера развивается очень быстро, и я допускаю, что ПО, написанное лично Виртом, в новых образцах уже не используется.
Кстати, ETH занимает одно из лидирующих мест в соответствующих исследованиях, уступая, возможно, лишь MIT.
Если Вам интересна история этого проекта, вот выдержка из диссертации о применении методов спутниковой навигации в беспилотных вертолетах.
The helicopter project was initiated in the late 1980’s by Prof. H.P. Geering,
head of the Measurement and Control Laboratory at the Swiss Federal
Institute of Technology (ETH) Zurich. Since the establishment of the
project, both theoretical as well as practical aspects have been covered. In
consequence, a remarkable laboratory environment for indoor testing of an
electrical helicopter has been developed.
Subsequent to successful flight experiments with the indoor electrical helicopter
(Weilenmann, 1994), the author was offered to continue and complement
the helicopter project with an unmanned, free-flying helicopter based
on INS/GPS navigation and modern control theory. During 1995 until 2000,
the Swiss Heli Team ETH, which was initiated by the writer, succeeded to
develop two helicopter prototypes, whereby the latter has demonstrated
completely autonomous flights, including lift-off and landing.
In 1996 the Swiss Heli Team ETH participated in the International Aerial
Robotics Competition which was organized by the Association for Unmanned
Vehicle Systems International (AUVSI). The Swiss team achieved
the second place behind the team from MIT. Subsequent to the successful
participation at the competition, Prof. W. Schaufelberger and Prof. N.
Wirth significantly supported the helicopter project for further developments.
Что касается идей.
Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.
Вы можете найти их и в языках Java и C#, и в JVM и в .NET.
Что касается учебной сферы, то по книгам, языкам и системам Вирта учатся во всем мире. (В частности, ETH Oberon System 3 изучается в ряде западных учебных программ. Я уж не говорю о том, как изучали ее код в Sun в начале 90-х годов. Очень творчески. )
Хочу отметить (как личное), что именно в книгах Вирта я впервые встретил примеры построения целых программ от начала до конца, а не общие рассуждения в стиле Буча.
Так что небезполезную жизнь прожил Вирт, как бы Вам, видимо, не хотелось доказать обратное.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, Serginio1, Вы писали:
AVC>>>Но там требовалась JIT компиляция. S>> Смысл дженериков не в джит компиляции, а в констрейтах. В net все подвергается джиту (за исключением Ngen).
AVC>Спасибо, я и правда почему-то в этот момент забыл, что в .NET все подвергается JIT. AVC>А хотел я сказать, что Оберон (как язык в целом, а не только Оберон.NET) может использоваться и в условиях, не допускающих JIT-компиляцию в момент загрузки (хотя сама эта техника "докомпиляции" при загрузке, кажется, именно в Обероне и появилась: в OMI — Oberon Module Interchange — для переносимости модулей из одной среды в другую). AVC>Возможно, поэтому дженерики и не входят в состав языка Оберон, что могут быть применены не везде. (Хотя до конца это мне неясно.) AVC>Ущерб здесь не для функциональности Оберона, а для статического контроля типов, на что обращалось внимание. AVC>Думаю, Вы правы — эту проблему можно решить экспортом "констрейтов".
А почему нв ВЫ?????
На самом деле дженерики это очень хороший подход. Впринципе давно существует понятие универсальный промежуточный язык, с последующей компиляцией в натив. MSIL как раз такой язык полностью типизированный и с метатаданными. Дженерики тоже хранятся в MSIL и легко типизируются.
Из этой длинющей ветки понял, что оберон по своей сути мало отличается от манагед сред, правда со своими особенностями.
Джнерики только появились пока в бетта версиях Net и Java и развиваются и появятся они наверняка и в Обероне
Так или иначе все наработки так и на голом месте ничего не вырастает.
Опять же если смотреть на Net то есть как обычный фреймворк так и компакт фреймворк для КПК. Наверняка найдется и область применения и для Оберон систем более широкое. И это прекрасно, что прогресс двигают не только промышленные монстры, которые правда больше заимствуют чем изобретают. И для совершенства нет предела.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
AVC пишет:
> Д>А где сейчас те языки, операционки и вертолеты? > По-моему об этом уже достаточно много говорили. > Видимо, подтекст такой, что сейчас это не используется?
Используется, но не широко.
> Это не так. > Паскаль используется.
В основном для обучения (для чего он замечательно подходит, кстати говоря).
> Модула-2 используется в космической промышленности (кстати, в том > числе в нашей стране), в авиапромышленности, в ПО для атомной энергетики. > Оберон-2 используется, например, в NASA.
Кем? Можете сказать в каких аппаратах был использован Оберон?
> Идеи, примененные в языке и ОС Оберон, давно уже признаны индустрией.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Ну я особо не вникал в код , интересно было посмотреть как там низкоуровневый аспекты реализованы, оказалось на асме (ну по другому никак). Только имхо, встроенный ассемблер — не очень удачное решение, проще отдельный ассемблер, переносить код на другие архитектуры лучше будет.
Если число ассемблерных процедур достаточно ограниченно, то последнее Ваше утверждение сомнительно.
Низкоуровневое программирование на самом Обероне вполне возможно, в некоторых случаях не воспрещается и использование процедур с машинным кодом.
Вы сделали слишком общий вывод из отдельного кусочка кода.
СГ>>Что каксается оберон-вирусов, то, думаю, это уже совсем другой вопрос. RRM>Вот этот вопрос принципиальный, если там все так просто с вирусами, то эту систему нельзя использовать там, где неквалифицированный (в хорошем смысле слова) пользователь запускает программы полученные на стороне. На атомной станции (вы писали, что там вроде оберон применяется) там понятно дело левых программ нет, их долго тестируют, проверяют и т.п. можно и на обероне писать.
На Обероне можно отследить использование низкоуровневых конструкций.
Даже просто не разрешить загрузку модулей, использующих такие конструкции, если так критична будет защита.
Как и в Модуле, низкоуровневые конструкции требуют специального импорта (SYSTEM), который нельзя скрыть. (В отличие от использования низкоуровневых конструкций в Си. Хотя, впрочем, в Си почти все конструкции низкоуровневые. )
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
