Easyelectronics.ru

переписываю кодогенератор.

и при всей своей "ненависти" к Си всегда считал, что в моем проекте кодогенерация в Си маст хэв.
но тут задумался а настолько ли must?

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

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

может у кого нибудь они найдутся?

проверил несколько проектов, производительность не отличима. размер бинарника в С++ иногда даже меньше....

наличие namespace и объектов избавляет от долбаных_трудно_читаемых_названий....

ну так как?

аргумент - нет компилятора C++ под МК.

а такие существуют? так чтобы не совсем дикая экзотика.

даже ардуинщики по сути С++ сники под капотом.

не...это экзотика. этому добру почти 20 лет

Может тогда PIC16 ?

Не, ну ладно еще С++, но не педеrust же!
А вообще, какой смысл на С++ под МК писать, если на С значительно легче и удобней?

Microchip is offering a special edition of our C++compiler software completely free. The MPLAB® XC32++ compiler software adds the flexibility to develop and reuse C++ projects and components with the added benefits of:

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

УМВР, все нормально. Что до разработки, на самом деле вообще неважно, на каком ЯП ты пишешь. Важно, насколько ты его понимаешь. Ну и, конечно, желательно на общепринятых ЯП писать, а не всяком говне, которым полторы калеки пользуются (я про до-диезы и прочие goвна).

https://ww1.microchip.com/downloads/en/ ... notes.html MPLAB® XC32 C/C++ Compiler for SAM and PIC32 MCUs

У стандартного С (на котором я так же предпочитаю писать под STM) нет "изоляции" от слова совсем, когда проект разрастается до 10 000 строк кода, это доставляет некоторые неудобства.

P\S Просто для информации:
https://www.opennet.ru/opennews/art.shtml?num=54918

Что значит "нет изоляции"?
А то, что педеrust включили в язык разработки под платформу корпорации зла, лишь подчеркивает его ненужность и ущербность!

тебя, как спеца по ненужностям и ущербностям хочу спросить...
не подчеркивает ли вот это случайно ненужность и ущербность линукса?

Должна быть. Если смотреть с позиции того, что предлагают производители МК, то без С никак. Если я могу легко в программе на С++ использовать библиотеки на С, то пользователям, крепко засевшим в HAL'е, будет трудно пользоваться библиотеками, написанными на С++. Если тебе интересны как пользователи твоего труда поклонники Mbed, то можешь забить на С.
Резюме: определись с целевой аудиторией, тогда станет понятна потребность в поддержке того или иного языка.

в том то и дело что HAL - это С, который всегда можно пользовать из С++. но не наоборот.

моя задача охватить как можно большую аудиторию, но не любой ценой


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

Невозможно задать область видимости функций и Enum
Это значит, что если где то в какой то библиотеке не дай бог совпадут названия перечисляемых типов, то сексуальные игры гарантированы, и тут вариант только один менять названия чтобы они не совпадали.

P\S ты же вроде сам попадался с этой ерундой когда писал USB под STM32

Научите писать на С++ под контроллер. Ну в смысле - покажите. Я без сарказма. Не умею, не понимаю. Под PC практически не писал. Про ООП много читал, но как применить на практике, тем более под мк - не пойму, не могу переключить голову... Ну и есть мнения, что ООП вообще не нужен, по крайней мере в прикладном, и всё прекрасно пишется в функциональном подходе - это подливает сомнений, так сказать.

C++ for the Embedded Programmer
STM32CubeMX IDE CPP Programming
Modern C++ in Embedded Systems
C++ для Микроконтроллеров | Урок 7 часть 1 | Программирование STM32F4 на CMSIS

и тд и тп

Для начала посмотри на HAL от STM. Кроме шуток. Сплошной ООП на С. Там тебе и наследование, когда полем структуры является другая структура, там и полиморфизм в виде вызова функций-обработчиков через массив адресов, и апофеоз в виде префиксов имён функций и данных а-ля, например, PCD, PCD_EP и тому подобное. Я уж не буду говорить о партянках в виде параметризируемых макросов, которые в чистом виде являются шаблонами. У меня вопрос к STM, почему просто не написать это всё на С++? Писать в ООП стиле можно ведь и на не-ООП языке, только, по-моему, это не физиологично.

Физиологично до определенной степени, когда нужно делать точечные оптимизации (например, ручную оптимизацию vtable'ов) и когда не очень умеешь управляться с плюсами.
Потом, конечно, да, становится труднее.
Мне в си не хватает даже не столько классов и полиморфизма, сколько шаблонов и constexpr. Вот с этим жизнь стала бы лучше, веселее.

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

к сожалению constexpr в обрезках С++ для эмбеда, чаще всего недоступно ибо появилось в С++ 11 в 2012

К счастью в большинстве процессоров и мощных МК он уже поддерживается.

Это как? И зачем? Первый раз такое слышу.

Пример из жизни - реализован в сях (буду в терминах ООП говорить) абстрактный класс ШИМ под разные виды инверторов двигателей: ДПТ,бесколлекторные,шаговые и т.д. Вместо vtable, который в контексте сей представлял бы собой массив указателей на функции, при инициализации абстрактного класса вносится в сам класс указатель на функцию-реализацию управления инвертором. Нужно это потому,что эта функция вызвывается с частотой 10 кГц в realtime цикле, и в случае с массивом указателей на фунции нам сперва надо было бы извлечь из класса индекс,по которому обращаться к массиву,затем из массива извлечь указатель, затем перейти по нему. В случае с встраиванием указателя на фунцию сразу в абстрактный класс у нас остается только извлечение указателя из класса и переход по адресу в указателе.
В данном случае это оправданная оптимизация. Конечно, в C++ тоже этого можно добиться, если статически обьявить экземпляр абсрактного класса и сразу же ему присвоить указатель на статическую же реализацию,но на момент, когда я эту работу выполнял, я об этом еще не знал. Ну и также не совсем доверял ARMCC компилятору в составе Keil.