Применение С++

[vavan1983]

Для МК стандартного C за глаза.

[NewWriter]

Я раньше тоже так думал. Пока не намучался на Си с навороченной графикой в GUI. Приходилось для каждого графического элемента создавать структуру и хранить массивы указателей на них.
Хотя простые вещи типа вон того чайника, когда он один, написать процедурным методом проще и понятнее, чем объектно-ориентированным.
Создавать объект "чайник", когда он один, действительно ну так себе... Тут и процедурный метод справится.

[mike-y-k]

Мелочь с 1kB памяти и, например TMS320, относятся к МК, но писать для TMS320 на чистом C можно только если нужен простой алгоритм с перемигивания светодиодами при первом попробовать…
Дальше или переписывать все библиотеки на C, или писать свои (при наличии уже работающих, но на C++)…
А если встает еще и вопрос применения на множестве МК, тогда преимущества C++ становятся еще очевидней…
Тема сильно перекосилась в сторону классической модели Windows vs unix…
Можно на том, что знаешь и на чем умеешь, а если таки уже не хватает - смотреть в сторону других возможностей…
C++ дает такое качество, а практически все IDE спокойно работают с ним…
Ну а дальше каждый решает для себя сам - получить рабочее и с минимумом ошибок завтра или еще неделю писать и отлаживать новую библиотеку под изменившиеся условия…
Часто это бывает просто дополнительная переменная с необходимостью работы с ней во множестве мест. В ООП это решается сильно проще и с меньшим числом ошибок…

[serg_42]

Непонятно только как это теперь к микроконтроллерам применить

Все библиотеки Ардуин написаны на C++. Весь код библиотек открыт, при желании можно разобраться и это даже полезно. Покупаешь у китайцев Arduino Nano на atmega328 с каким нибудь простеньким дисплеем и вперёд...
Только есть одна проблема - чем чаще юзаешь Ардуиновские библиотеки (не выходя за пределы интерфейсной части), тем быстрее тупеешь.

[МВА]

Для МК стандартного C за глаза.

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

Продолжение "меркер vs маркер" тут

…

[NewWriter]

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

[eddy]

намучался на Си с навороченной графикой в GUI

А чего там мучиться? Берешь nuklear, да пишешь.
Но лично я и длинной палкой GUI касаться не собираюсь! Если твоей железяке категорически нужен GUI (картинку, например, показывать), проще всего веб-морду нарисовать, чем возиться с тем же nuklear (а потом вдруг окажется, что на другом дистрибутиве это не взлетит).
Но правильней всего писать такой софт, где никогда не понадобится GUI.
Что до ЯП, лично мне за глаза С хватает. Правда, иной раз приходится там эдакую ООПщину реализовать. Коллега ржет, что я изобретаю новый С++. Но мне органически противен С++, и уж тем паче — современный, со всеми этими наворотами, шаблонами и т.п. И rust я однозначно пользовать не буду, т.к. зачем вообще на что-то с идеального С соскакивать? Кроме того, на С я могу писать как под МК, так и под ПК (все мои сетевые демоны и т.д., и т.п. - на сях).

МВА, а у меня вот такой простейший КА для определения состояния кнопок:

Нажмите, чтобы открыть спойлер

void process_keys(){
    static uint32_t lastT = 0;
    if(Tms == lastT) return;
    uint16_t d = (uint16_t)(Tms - lastT);
    lastT = Tms;
    for(int i = 0; i ‹ BTNSNO; ++i){
        keybase *k = &allkeys[i];
        keyevent e = k-›event;
        if(BTN_state(i)){ // key is in pressed state
            switch(e){
                case EVT_NONE: // just pressed
                case EVT_RELEASE:
                    if((k-›counter += d) › PRESSTHRESHOLD){
                        k-›event = EVT_PRESS;
                    }
                break;
                case EVT_PRESS: // hold
                    if((k-›counter += d)› HOLDTHRESHOLD){
                        k-›event = EVT_HOLD;
                    }
                break;
                default:
                break;
            }
        }else{ // released
            if(e == EVT_PRESS || e == EVT_HOLD){ // released
                if(k-›counter › PRESSTHRESHOLD) k-›counter = PRESSTHRESHOLD;
                else if((k-›counter -= d) ‹ 0){
                    k-›event = EVT_RELEASE; // button released
                }
            }
        }
        if(e != k-›event){
            k-›lastTms = Tms;
            lastUnsleep = Tms;
        }
    }
}

[NewWriter]

лично я и длинной палкой GUI касаться не собираюсь!

Ну это лично ваше дело. Далеко не все с этим согласны и не всем интересен такой динозавризм.

Но правильней всего писать такой софт, где никогда не понадобится GUI.

Угу. Ну сделайте часы-будильник без индикации Чисто для поржать - время будильника устанавливать будете по числу "пиков" или через веб-интерфейс?
Глупости сочинять то не следует.

Си - хороший язык низкого уровня с большой свободой действий. С++ - первая ступень языков высокого уровня, позволяющий более организованно описывать "высокие материи". Конечно, у него немало недостатков, поскольку он вышел из языка Си. И в процессе развития версий старые проблемы не устранялись, а заменялись надстройками. Например, все знают проблему дублирования понятий typename и class в шаблонах (только в STL появляется различие, да и то искусственное), смысловое дублирование class и struct, отсутствие компактного типа string.

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

void process_keys()

Агааа, то есть компилятор в режиме С++ всё-таки ) ну-ну, ну-ну.

[eddy]

сделайте часы-будильник без индикации

На компьютере у меня такие уже есть: команда date (да и вообще, у меня PS1 так настроен, что там сразу дата и время выводится - удобно).
А если имеются в виду аппаратные часы, то тоже не всегда индикация нужна (скажем, если мы коннектимся по какой-нибудь шине). А если нужны, то таки для МК сделать графику - проще простого. Берем тот же семисегментник, вуаля! Ну или светодиодные матрицы. Да даже TFT - фигня же!

динозавризм

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

компилятор в режиме С++ всё-таки

Компилятор - обычный gcc, что такое "режим С++"? Я пользуюсь С99, всякие новомодные навороты обычно не использую. И код здесь - классический сишный в стиле С99.

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

Да ладно! Тот же VladislavS показывал хорошее решение. Пока ты все эти пины активируешь, компилятор просто накапливает "настройки" этих шаблонов. А когда компилятор на реализацию натыкается, то просто все это вываливает в одном месте. И получается, что куча разбросанных по разным местам настроек реализуются тупо изменением за один присест значений регистров настроек ног.

[NewWriter]

Динозавризм - это использовать C99 и полагать, что если тебе не нужно больше, то это никому не нужно. Это недалекость мЫшления, однако.

все эти пины активируешь, компилятор просто накапливает "настройки" этих шаблонов.

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

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