Объемное - нет и не собираюсь.
http://sasamy.narod.ru/l4fiasco_at91.patch.gz



Тут ключевое слово - было, на С и С++ пишут сейчас.



Во многих случаях - это я хватанул конечно мне достаточно того что С++ не имеет никаких преимуществ при этом очень сложен, чтобы стать хорошим программистом С++ нужен не год и не два.

Было время, когда в тогдашнее «сейчас» писали на асме и фортране, а С только появился. Тогда было «на асме, фортране и С пишут сейчас». И тогда было «большинство ОС написаны на асме, прикладного софта — на асме и фортране». С уже существовал. Вот тогда его и надо было Вашими аргументами убить.
15 лет назад в эмбеддерских кругах любители ассемблера (в основном — просто незнатели С) наскакивали на С точно так же, как и сейчас Вы на С++. При том, что с точки зрения инструментария ситуация с С в ембеддед была приблизительно такая же, как сейчас с С++ — для большинства архитектур есть.
По поводу одного из аргументов (про несогласие потративших время с тем, что они потратили его зря) я уже говорил, добавив этот
могу только процитировать «и то, и другое я видел не раз — кого ты хотел удивитть?» (в смысле точно такой же аргумент, только без символов ++ и против С, а не за него, — я уже слышал).

Я прошу один, в котором язык С++ уступает. «он слишком сложен» — не катит. Хотя бы потому, что он уже применялся против С, а не за него. И потому, что многие пользующиеся С сейчас — так его толком и не знают (надо-то тоже «не год, и не два»).
А если ограничиться частью С++, то тоже не так и сложно. У меня же кое-что получается :-)

sasamy,
вот у меня в соседней ветке конкретный вопрос

сам давно (очень) делал на плюсах, сейяас просто C, поэтому задал там вопрос

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

Чего вы привязались к этому C++ ? Я естественно не авторитет в выборе языка и высказываю свое мнение, но если интересно - например не новичек в C/C++ и действительно авторитетный человек вот что говорит:

http://www.minix3.ru/articles/Tanenbaum_interview_en.html


Язык программирования Cyclone

Сообщение отредактировал sasamy - Dec 22 2011, 08:34

Это мы привязались? Прозвучало как «пошла ты нафиг со своим утюгом» из анекдота.

«мнения» бывают разные. Одно дело «мне язык не нравится, какой-то он перенавороченный» — это оценочное суждение и, вопрос вкусовой.
Но
это уже конкретное обвинение. Потрудитесь обосновать. Не переводя стрелки на Cyclone или, скажем, D, который мне импонирует.

Он говорит, что С++ не был выбран потому, что тогда, в 1987, он еще не слишком широко использовался (от меня: да и был он тогда ещё без многих современных возможностей, хотя многое из ручной работы уже автоматизировал). И что это у него была больше дань традиции, чем идеологии. И что если он когда-то будет куда-то переходить, то это будет С-клон. Т.е. конкртеное решение конкретного человека в конкретных условиях. И ни слова не сказал о том, что ему не нравится С++ чем-то конкретным. «It is more legacy than ideology»

Теперь передвинем этот текст на пол-периода в прошлое, другие люди и другой проект. И получим что-то в духе

— Почему как язык разработки был выбран Фортран? Собираетесь ли вы переходить на другой язык, например, С?
— Мы начинали в 1975. С ещё мало был тогда распространён. Если мы когда-то перейдем, то, возможно, на ADA

Было бы это аргументом против С в 1985 году?

А если я теперь против Cyclone применю ваш аргумент?
«Приведите мне примеры ОС, для микроконтроллеров и малых микропроцессоров, написанные на С-клоне. А вот на С++ больше написано»
Вы сможете защитить С-клон?

С++ хоть и давно существует, но в embedded-области еще новичок. Как бы «только-что появился», так как процессоры, применяемые в этой области, только стали подтягиваться к достаточному уровню.

Ситуация очень похожа на положение С в embedded 15-20 лет назад. К тому моменту С уже давно существовал и прочно сидел в области «больших» процессоров. Но для «мелочи» частично не пролазил по объёмам ОЗУ/ПЗУ, частично — по (не)привычке, инерции и «неосвоенности». И когда уже разобравшиеся с ним за него агитировали — против С звучало всё то же, что тут прозвучало против С++. И до крайностей в духе
— Это вы понтуетесь тем, что разобрались, так как кроме как для понтов это не годится. А нам некогда понтоваться, нам работать надо.

И звучало, даже с линками на зачаточные компиляторы, такое:
— вот если бы Модула, или хотя бы Паскаль нормальный, вот это да...

Так и где сейчас в нашей области модула с паскалем? Насколько много осталось ассемблера? А где С?
Вот доживём, посмотрим на С-клона в сравнении с С++.
Если микро-дот-нет не задавит обоих :-)

p.s. Когда почти 15 лет назад в упомянутой RU.EMBEDDED dxp уже начинал говорить о С++ — я тоже слушал недоверчиво :-)

Под "привязались" я имел ввиду что вы уцепились за С++ как за панацею и явно ожидаете что в ближнем будущем все будут писать на С++ как сейчас на С.



Скажем макросы - мощнейший инструмент кодогенерации в С и головная боль в С++



На вполне конкретный вопрос про С++ он ответил что сегодня если бы и стал переходить то на cyclon - я специально ссылку дал - это все тот же старый добый С но который реально решает проблемы безопасности кода и С++ там даже близко не пахнет так как он ни одной этой проблемы не решает.

Потрудитесь развернуть свою мысль. В чем именно головная боль?

Потрудитесь книжки почитать
http://www.programmer-lib.ru/cstandart_page.php?id=9

Макросы в голом Си настолько-же опасны как и в С++, но в последнем есть возможность их много реже использовать:
- типизированные константы;
- inline функции;
- шаблонные функции;
- шаблоны классов.
Эти возможности успешно заменяют макросы и превосходят их в 99% случаев.
Но в 1% макросы нужны и в С++, поэтому они в нем есть.

Вот эта часть цитаты

автор - я.

По ходу, автор ссылки сам текст по ней не читал, ибо там чётко и конкретно сказано:

Т.е. опять всё наоборот: заявлено, что в С макросы - могущество, а в С++ - геморрой (хотя и там, и там макросы - суть одно и то же, потому и могущество с геморроем несут одинаковое), а по ссылке чётко и конкретно сказано, что как раз-таки в С++ проблема с макросами решена на 99% именно средствами языка.

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

А за сайтик http://www.programmer-lib.ru - спасибо!

Эти возможности вообще нихрена не могут в кодогенерации по сравнению с макросами





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

Сообщение отредактировал sasamy - Dec 22 2011, 17:32

ПМСМ, разногласия С-филов и С++-филов не отражают ничего, кроме разницы в характерах самих оппонентов.
Дело в том, что кому-то достаточно сложно далеко абстрагироваться от первоначальных объектов, а кому-то нет.
С++ характерен тем, что гораздо более полно отражает кактусы, пустившие корни в голове программиста.
И если кто-то классифицирует (в смысле С++) объект так-то и так-то, то другой может и не разобрать то, что наворотил первый.
Поскольку имеет свои представления об этом же объекте.
В корне отличающиеся от представлений первого.
Чтобы не быть голословным, попрошу уважаемое сообщество создать класс "машины электрические".
А там посмотрим - у кого что выйдет...

Это вряд ли. Скорее это зависит соотношения "сложность задач/доступные ресурсы (время/трудоёмкость). Попробуйте, например, GUI написать на С и С++, разницу поймёте сразу.


Тут уместно другое сравнение. Вот в С структуры уместно использовать? Ну, чтобы вместо использования пачки связанных по контексту задачи переменных упаковать их в структуру. Упрощает работу с данными - согласитесь, что работать с таким агрегатным объектом много удобнее - вместо нескольких мелких сущностей получаем одну более крупную. Когда подобных объектов в программе набирается с полдюжины, то структуры вообще начинают рулить (на любом языке, кстати - вон в SystemVerilog есть поддержка структур, так они очень сильно облегчают работу по сравнению с классическим Verilog'ом).

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

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

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


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