Как наши писали компилятор С++ и что у них получилось.

баян

Ну и что, какая разница какой давности? Я же честно предупредил, что
статья не новая. К тому же сылок на неё на ЛОРе я не нашёл и хотя она
написана в 1997 года читается и сейчас интересно и поучительно.

Вот ещё статья Евгения Зуева, он предлагает в ней русифицированый
вариант языка C++ с конструкциями вроде

шаблон<цел Размер, тип Тип>
класс СТЕК {
Тип* Массив;
цел Вершина;
всем:
// Конструктор и деструктор
СТЕК () : Вершина (0), Массив (создать Тип [ Размер ] ) { }
~СТЕК () { удалить [ ] Массив; }


http://www.interstron.ru/txt/PaperEAZ_RusPlus_Ru.htm

Выглядит дико непривычно, но в отличие от многих, он как один из
создателей компилятора C++ знает о чём говорит.

Кстати, там описано как тестировался компилятор и какие были сложности.

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

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

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

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

http://www.space.edu/projects/book/chapter17.html

> The US had tried to send Mariner 1 to Venus, but a programming error resulted in the craft's destruction less than five minutes after its launch.

> In 1988 the Soviets launched two probes to Mars called Phobos 1 and 2. Both probes failed due to computer errors from initiated commands.

> The probe reached the Moon and obtained over 1.6 million images; on its way to Geographos, Clementine rendered inoperative by a computer commanding error which started spinning the entire spacecraft and depleting its fuel.

Bugs 4ever короче.

В многопоточных приложениях баги следует извлекать пи-исчислением. Многое конечно определяется архитектурой проги. Однако Из ашыпак есть просто очяпятки, которые бывает очень хитро выловить. Например, только что нашёл багу, которая образовалась заданием константы 1 вместо нужной переменной при вызове функции. %)

естесенно ;)

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

А что касается отладки, хорошо, если вопрос только в правильнйо синхронизации... А если ты с архетектурой напортачил?.. А?.. Какого костыли придумывать... ;)

Как же тут стиль поможет, если вместо i начяпятал 1? Ищщи потом ветра в поле :(

Архитектуру как раз и следует отлаживать, ещё до того как за кнопки сел. Есть слухи например, что прога на С чревата мемори ликами. Так вот, умя в прогах ни разу ни одного не было и быть не могло, как раз потому, что эта фича архитектурно не поддерживалась.

:)

а если бы ты использовал переменные вида a, b, c... то ты легко бы заметил разницу между i и 1 ;)

Есть личности которые проектируют за компом... Хотя я люблю бумажку с ручкой...

> то ты легко бы заметил разницу между

На моём шрифте разница между i и 1 очень заметна, не в этом дело. Это ж сырцы читать нужно, а там иногда такое понаписано...

Сенькс за ссылку. Уже читал, но с удовольствием перечитал ещё раз.

Хороший текст, полезный.

>Любителям разгадывать псевдонимы и умолчания сказанного вполне >достаточно, чтобы узнать страну, компанию, да и ее представителя.
Что-то не узнаю в гриме... Кто это ?!!

> Выглядит дико непривычно, но в отличие от многих, он как один из создателей компилятора C++ знает о чём говорит.

В главе "Почему нужно переводить" ни одного арумента в пользу перевода нет. Зато жизнь подсказывает вагон "против". Например, какую кодировку будет поддерживать компилятор (хотя, для учебной системы это не столь важно)? Да и всякие служебные символы типа []{}$&`~ в русской раскладке отсутствуют, следовательно - геморрой.

Статья-то, на самом деле, не про компилятор :) А про то, что было бы желание, а работать и зарабатывать можно и в России. Ну, ещё про то, что C++ - suxx, но денюжку за него платят :)

>> In 1988 the Soviets launched two probes to Mars called Phobos 1 and 2. Both probes failed due to computer errors from initiated commands.

Программное обеспечение самих фобосов не при чём. Разве только тем, что защиты от дурака не было, но предполагаю что никаких набортных ресурсов не хватило бы.

Сначала первый, ещё на пути к Марсу, а потом и второй фобос уже на орбите угробили операторы в ЦУПе, причём одинаковым методом. На Земле находились имитационные дубли Фобосов и все команды предварительно, перед посылкой настоящим фобосам, проверялись на нём, а тот имитировал их состояние. Так вот, сначала на первый фобос подали команду без предварительной отработки, как якобы простую, но которая привела к потере ориентации, так потом повторили уже и с другим такую же бяку.

> Что-то не узнаю в гриме... Кто это ?!!

Я признаться тоже не понял.

Данные следующие:

1) Компания имеет (или имела) в начале 90-х годов свой вариант Unix.

2) Компания в середине 90-х годов была уже около 20 лет на рынке.

3) Году в 95-96 были серьёзные финансовые трудности.

Уж не Novell ли это?!

Хотя компания была европейской, так что видно не Novell, но у кого ещё были свои версии юникса? Приходит на ум из европейских Siemens, но он же явно старше 20 лет, да и известность большая, а Зуев сказал, что мол фирма известная, но не у всех на слуху.

> Архитектуру как раз и следует отлаживать, ещё до того как за кнопки сел.

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

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

Могу тебя уверить, что при разработке и доводке любого летательного аппарата внимание отладки уделют офигенное. Только сам процесс называется не отладкой, а моделированием и испытаниями. До того как собрать самолет и запустить его "полетать" проводятся стендовые испыстания и различные виды моделирования составных частей конструкции: управляющей БЦВМ, другой бортовой электроники, всяких рулевых приводов, двигателей, физюляжа и т.д. Это понятно почему, цена любой ошибки в hardware или software самолета - чья-то жизнь и/или десятки/сотни тысяч багзов.

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

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

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

В Европе было несколько компаний, которые вплотную занимались UNIX. Это - ICL, Olivetti, Nixdorf, Bull и Siemens. Эти компании даже в прессе прозвали BISON (по первым буквам). Если смотреть по тексту, то эта компания должна очень плотно быть ориентирована на SPARC. Насколько мне известно, именно ICL ориентировалась на SuperSPARC. Осталось проверить информацию о финансовоых трудностях.

Novell - это не европейская фирма, а вот предположение о Siemens очень может быть похожим на правду, так как речь может идти не о всей фирме, а о каком-то подразделении, которое занимается непосредственно UNIX, выч. техникой.

Я даже не знал, что эти компании, кроме Siemens занимались юниксом. Но Siemens кажется поглотил Nixdorf, так что это не Siemens однозначно.

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

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

Попробовал поискать в интернете, ничего не понятно. ICL поглощена Fujitsu у Olivetti и Bull ничего похожего на C++ не нашёл.

>Но Siemens кажется поглотил Nixdorf, так что это не Siemens однозначно.

Точно и назывался Siemens Nixdorf Informationssysteme AG. Выпускал ось под названием SINIX до версии 5.42. Которую позже переименовали в Reliant UNIX.

Как-раз в 1996 году британская ICL закрыла последнее свое предприятие по производству мэйнфреймов своих.

http://www.mitem.com/solutions/platforms/ICL.asp

Olivetti базировалась на Intel. Siemens Nixdorf - на MIPS, Bull - на Power PC. И только ICL - на SPARC и SuperSPARC.

Кстати, поиску могут быть неправильными. вот из статьи кусок.

>Однако то, что говорил высокий солидный бородач (назовем его Вальтер Деккер), звучало как откровение. Предлагалось разработать (не адаптировать не доделать, не участвовать в разработке, а самим сделать from scratch - с нуля!) компилятор (компилятор!) с языка Си++ (!) для одной европейской (для определенности пусть для бельгийской) софтверной компании!"

Итак, европейская *софтверная* компания.

>Фирма хотя и не обладала именем, звучащим в мировом масштабе, но казалась вполне респектабельной: она существовала уже более 25 лет, что для софтверной фирмы, согласитесь, немало, участвовала в нескольких общеевропейских проектах; ее продукты (в том числе, собственная коммерческая реализация UNIX) имели не одну тысячу пользователей. (Любителям разгадывать псевдонимы и умолчания сказанного вполне достаточно, чтобы узнать страну, компанию, да и ее представителя. - Е. З.) Вполне логичным выглядело желание дополнить свою систему программирования новым мощным языком.

Так что можно и не отыскать концов. Это фирма, имеющая собственную систему UNIX. То есть она должна иметь лицензионное соглашение с SCO (или кто там тогда владел правами на UNIX?). Из этого списка, если таковой найдется, можно узнать многое.

Новая информация. Действительно, у Fujitsu-ICL был свой собственный UNIX, который назывался DRS/NX. И система программирования (термин интересный) была обширная: http://www.itb.hu/ajanlasok/a6/html/prods/icl.htm

А вот под нашей компанией, которая собственный процессор разрабатывала, имеется в виду, наверное, НТЦ "Модуль" (http://www.module.ru). На это меня натолкнули его статьи Зуева по программированию под нейропроцессор. Именно "Модуль" разработал нейропроцессор NeuroMatrix. К тому же, у НТЦ "Модуль" в программном обеспечении гордо красуется "компилятор С++" и "оптимизирующий компилятор С++". :)

P.S. Кстати, нейропроцессор у них лицензировала все таже Fujitsu. На его же заводе его и делали. У меня тут пара PCI-плат с ними валяется.

Интересно, получается это действительно ICL. Спасибо за ссылку на НТЦ "Модуль", правда тактовая частота того процессора 40 МГц не очень впечатляет, но ничего -- у человеческого мозга она, вообще всего 10-15 Герц ;-))))

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

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

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

> прочитал бы искуство програмирования от кернигана

Практика программирования у него называется. А искусство -- это у Кнута. Но я о том, что правильно поставленные тесты вещь хорошая, но на примере статьи о написании компилятора видно, что недостаточная. У них получилось, что как только стали нормально отрабатывать 95% тестов, то остальные 5% оказались весьма нетривиальными для отладки.

>Но я о том, что правильно поставленные тесты вещь хорошая, но на примере статьи
>о написании компилятора видно

и где видно что недостаточная?

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

а если уж речь зашла о Кнуте,
то он написал прекрасную статью о тестирования и отладке TeX, советую почитать.

Я так понял, что сложность отладки при приближении к 100% прохождения тестов, у них стала расти экспоненциально, если не хуже.

> а если уж речь зашла о Кнуте, то он написал прекрасную статью о тестирования и отладке TeX, советую почитать.

Спасибо, я и не знал, что есть такая статья. Если url не подкинешь, придётся мне самому гуглить ;-)

>Я так понял, что сложность отладки при приближении к 100% прохождения >тестов, у них стала расти экспоненциально

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

>Спасибо, я и не знал, что есть такая статья. Если url не подкинешь, придётся мне >самому гуглить ;-)

в "практике программирования" от кернигана была ссылка, кажись.

Только там ссылка не на статью, а на книгу Кнута, TEX: The Program. Я её не читал, не знаю, переиздавалась ли она.

Это и есть сам TeX. Книга тривиально генерится из исходников TeX-а...