Отправлено Oldring 06 марта 2005 г. 22:07 В ответ на: Уважаемый Oldring, хотя бы одну причину я назвать, наверное, смогу ;). отправлено A_S_N 06 марта 2005 г. 17:28

Он полноценный универсальный язык программирования, почти что Ада. Не объектно-ориентированный, конечно, но и модели устройств все-таки, как правило, не настолько сложные, чтобы ООП давал большие преимущества перед классическими языками программирования. Кроме того, ООП и С++ - это не одно и то же. И на VHDL можно писать объектно-ориентированно. Это все-таки гораздо проще, чем пограммировать объектно-ориентированно на ассемблере, например. :)

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

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

Но, к сожалению, как показывает практика, наиболее популярными часто оказываются далеко не лучшие инструменты. Сегодня как раз откопал на своей книжной полке книжку Джехани "Язык Ада" и пролистал её впервые за много лет. Кстати, автор написал её в 1983 году, и он являлся сотрудником тех же Bell Labs, где родился Юникс с Си. Знаете, какая у меня мысль возникла? "Блин, да ведь этот язык на голову выше Си! И, в отличие от Паскаля, позволяет писать все - вплоть до ассемблерных вставок и контролируемо-неконтролируемого преобразования типа!". Кстати, как раз при программировании всяких 8-ми и 16-битных встраиваемых процессоров при использовании Ада можно получить наибольшый выигрыш в оптимизации кода по сравнению с Си. Не говоря про инкапсуляцию, перегруженные операции и встроенные в язык средства многозадачности. Но только Вы много компиляторов Ада для встроенных систем встречали в своей практике? Нет, вместо этого все шире и шире начинают использовать для встраиваемых систем этот кошмарный STL с плюсами! Вот только простота и дешевизна использования С++ и других высокоуровневых инструментов для встраиваемых систем обманчива. Вы не видели железо с встроенным Linux, в котором никто не может вычистить все глюки? Я - видел. А все от того, что задачу пытались решать более сложными средствами, чем были необходимы для её решения.

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

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

1. Это не С++ и не может быть полноценным С++ - значит, чтобы код был синтезируемым, программисту прийдется писать на "Синтезируемом С++", изучая отличия и тонкие ограничения.

2. Основная модель железа - это многочисленные мелкие параллельно работающие процессы. Модель исполнения С++ - это один последовательный поток управления. Следовательно, должен существовать верхний уровень, описывающий параллельную структуру системы. И только внутри каждого процессика может существовать последовательный С++ код, описывающий внутреннюю _последовательную_ структуру процесса. Каждый такой процесс не будет слишком большим, значит, от использования С++ выигрыш не слишком большой.

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