Зато вывод сделать было не лень.

там нет никаких выводов - есть результат компиляции

Отлично, только я вот для микроконтроллера C99 (с некоторыми оговорками, типа отсутствия VLA) предпочитаю - по соображениям портабельности, предсказуемости и понятности мне того что компилер вытворять удумает. И вот как-то именно в сях - эти литералы ну вот не стандартизировали. И какая мне разнца что там в 14-х плюсах? Это другой ЯП, я им не пользуюсь, и он даже жуется другим бинарником компилера в случае gcc. Так что номинально грешок за мной водится, увы. И как угодно но свои огрехи в случае МК как мне кажется лучше знать. Чтобы понимать на что расчитывать.

Я gcc'ом LTO+GC секций научился делать, на более менее крупном (более ~4-5kb) коде добрая четверть кода нахаляву урезается. В том плане что логика не ломается, скорость не проседает - и все это просто потому что с LTO делается глобальная оптимизация, по всему коду. Это делает кодогенерацию довольно чудесатой, и иногда умеет прикалываться. Иногда даже перестановка statement местами меняет размер. Но работает круто. Особенно когда есть где развернуться. В этих примерах LTO + GC sections не используется и это соответствнено не максимум что можно извлечь из GCC. Может ли clang что-то сравнимое и насколько это (не)эффективно и (без)глючно пусть фаны clang исследуют. В силу природы оптимизаций оно может и поприкалываться.

Ты прекрасно знаешь, что я предпочитаю жить без анальных зондов!
Исключительно свободное ПО!

Бред-то какой! "Резко и внезапно" помереть разве что мастдайка может…

Именно из-за таких мелочей и стоит даже С код компилировать С++ компилятором.

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

Вообще-то, все STM32 прекрасно компиляются при помощи gcc! Возможно, когда-нибудь еще в сторону Cortex-M4 посмотрю (просто пока что у меня нет таких задач, где нужно было бы использовать флоаты или просто более шустрое ядро).
Сейчас вот на досуге ковыряю CH552G (и тоже для работы с ними ничего анально огороженного использовать не нужно!). Занятные мелкоконтроллеры. Жаль только, оперативки мало и периферия небогатая. Но для применения в качестве элементарной управляемой розетки вполне сгодится.

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

Да меня и сишный устраивает, апгрейдить требования с C99 до C++14 я не планирую. Это бред сивой кобылы, что-то подобное я только у виндовых дев с студией, но они это потому что поддержка C99 в студиях лютое гэ, поэтому такой вот "си++", внутрях чистый си, а из ++ аж //целые. Не хочу уподобляться. И в этом месте я лучше формально признаю что юзаю "нестандартный" гнутый экстеншн чем скажу что это C++14. Настоящие плюсовики меня не поймут, а юзать полновесный C++14 в мк в мои планы не входит.

Gcc и под F1xx вроде нормально работает, а то что он свободный - так это хорошо, не получится так что корп утащит в свое логово, а остальные обломятся. Под F4 тоже собирает, но у меня этих монстриков просто нет, не надо мне столько, да и на тех кто F4 на асме пойдет наворачивать я бы посмотрел

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

А при чем тут крестик и трусы? Я разве где-то настаивал что МК можно программировать используя только стандартные элементы яп?

Мысль номер раз: микроконтроллеры невозможно программировать используя ТОЛЬКО средства C или C++ прописанные в стандартах ЯП! А хотя-бы потому что средства контроля лэйаута прошивки (конкретные секции, адреса, стэк и прочие линкерскрипты, ...) - в стандарты ЯП вообще не входят. То-есть программируя МК мы точно залетаем на использование нестандартных расширений. А, ну еще на ассемблере можно. Но большой вопрос насколько нужно. Меня на С не обламывает сказать что-то типа ... SECTION(".vector"). А то что дефайн где-то дальше компилерспецифично раскрывается - фу, конечно, но не фу-фу-фу. И для другого компилера можно это просто переделать, много усилий не займет.

Мысль номер два: лучше называть вещи своими именами и трезво оценивать последствия тех или иных решений. А юлить про стандарт GCC - здорово, конечно, но какой организацией "стандарт" ратифицирован?

Мысль номер три: я не хочу использовать 14-е плюсы. Особенно - ради одной мелкой плюшки, что является издевательством над здравым смыслом. А коли я и так попал на использование гнутых расширений, за 0b... меня никто явно не съест. Тем более что вот это жрали вообще все виденые мной компиляторы, статические анализаторы и прочее. К тому же я в курсе что выхожу за пределы стандарта, а не разглагольствую про "стандарты gcc".

Так что да, я в отличие от трусов и крестиков предпочитаю более рациональные подходы. Поэтому я не против асма - если это что-то дает, кроме лишней долботни. Ну вот уверенность что за конструкция там будет - дает. Лучше чем упование на кодогенератор и оптимизатор, как по мне. И расширение я могу использовать. Если плюсы (e.g. более адекватный вид битовых полей) перевешивают минусы (теоретически становится менее портабельно). А про крестик и трусы я скажу тому кто откровенно сишный сорец обзовет 14-ми плюсами за аж целые 0bXXXXX

Всё это словоблудие, а в реальности стандарт на программирование микроконтроллеров ARM задают три основных компилятора плюс CMSIS для кортексов. А плюшки плюсов это далеко не только 0b или 0b0101'1010, но и более строгий контроль типов, более удобное объявление переменных, констант и типов и т.д. и т.п. даже практически не выходя за привычный синтаксис. И основные компиляторы для ARM давно C++17 поддерживают. Не задумывались зачем?

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

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

А зачем C++17? Наверное для вон тех монстров которым чуть не Qt embedded с чуть не оконной системой подавай.

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

Менюшка, menuItems - это массив структур во флеше, инитится он в виде удобном для человека, там нет никаких связей между Parent/Child/Next/Prev, как в микроменю. Внутри класса Menu этот массив передается в другой класс на полторы страницы который его трансформирует, там уже есть Next/Prev, но в виде индексов для которых автоматически выбирается минимально возможный тип, а Parent/Child по-прежнему нет, вместо них используются флаги типа Node. В итоге от простоты описания меню приходим к компактной и эффективной форме его хранения, а разместит компилятор этот новый трансформированный массив также во флеше, вместо старого, даже при отключенной оптимизации. Полторы страницы не самого простого кода, ведь нужно многократно обходить весь массив в поиске связей, в рантайме гарантированно не делает ничего потому что от языка программирования можно это явно потребовать, куда уж предсказуемее.

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

Menu<lcd, menuItems> menu(...) - на си наверное тоже можно нечто сравнимое сделать. Но вот лично меня МК интересуют не отрисовкой меню. А жестко реалтаймным управлением всяким, измерениями и проч. И предсказуемость волнует не в менюхе. А где-нибудь на стыке координирования железок, и всем таком. Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует. Ну, если не понимать под таковыми только 0bXXXX, при сплошных сях вокруг

Многократно замечал как С-программисты только увидят у файла расширение .cpp и давай сразу шпарить классами с виртуальными методами, вариативными шаблонами, приправляя всё это лямбдами, оператором "<=>" да концептами что аж профи позавидуют. Правда смешно звучит?

С какой стати? Тот же стартап.

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

Причём тут язык? Вы либо понимаете как работает железка, либо нет.

В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать. А так то когда вам кто-то черный ящик прилинковал, конечно, поди там разберись есть ли разница.
Интересно, а сколько для этого asm дампы читать пришлось? На сях то удобную процу конструкцию довольно тривиально размудрить . Ну и вон serial.begin'щики этим редко могут похвастать.
При том что когда я на сях пишу мне более-менее понятно во что это скорее всего компилер трансформирует. Без всенепременного вштыривания в ассемблерный кусок каждый раз. С навороченной си++ штукой с какими-нибудь классами и прочими это как-то менее очевидно.

Сравнивали много раз, C++ вариант ногодрыжной либы самый умный и эффективный, оптимизирует как на уровне пинов, так и на уровне работы с регистрами. В качестве иллюстрации, вот так выглядит одна из функций оптимизации:

Спойлер

Код:

   template<uint32_t Mask>
   static void _inline_ writeReg32(volatile uint32_t* reg, uint32_t value)
   {
      using vu8 = volatile uint8_t*;
      using vu16 = volatile uint16_t*;

      if constexpr (Mask == 0xFFFF'FFFF)
         *reg = value;
      else if constexpr (Mask == 0x0000'FFFF)
         *vu16(reg) = value;
      else if constexpr (Mask == 0xFFFF'0000)
         *(vu16(reg) + 1) = value >> 16;
      else if constexpr (Mask == 0x0000'00FF)
         *vu8(reg) = value;
      else if constexpr (Mask == 0x0000'FF00)
         *(vu8(reg) + 1) = value >> 8;
      else if constexpr (Mask == 0x00FF'0000)
         *(vu8(reg) + 2) = value >> 16;
      else if constexpr (Mask == 0xFF00'0000)
         *(vu8(reg) + 3) = value >> 24;
      else if constexpr (!(Mask & 0xFFFF'00FF))
         *(vu8(reg) + 1) = (Mask == value) ? *(vu8(reg) + 1) | value >> 8 : *(vu8(reg) + 1) & ~(Mask >> 8) | value >> 8;
      else if constexpr (!(Mask & 0xFF00'FFFF))
         *(vu8(reg) + 2) = (Mask == value) ? *(vu8(reg) + 2) | value >> 16 : *(vu8(reg) + 2) & ~(Mask >> 16) | value >> 16;
      else if constexpr (!(Mask & 0x00FF'FFFF))
         *(vu8(reg) + 3) = (Mask == value) ? *(vu8(reg) + 3) | value >> 24 : *(vu8(reg) + 3) & ~(Mask >> 24) | value >> 24;
      else if constexpr (!(Mask & 0xFFFF'0000))
         *vu16(reg) = (Mask == value) ? *vu16(reg) | value : *vu16(reg) & ~Mask | value;
      else if constexpr (!(Mask & 0x0000'FFFF))
         *(vu16(reg) + 1) = (Mask == value) ? *(vu16(reg) + 1) | value >> 16 : *(vu16(reg) + 1) & ~(Mask >> 16) | value >> 16;
      else
         *reg = *reg & ~Mask | value;
   }

Так наверное или можно? Допустим есть такой массив:

Можешь попытаться на его основании создать реверсный массив который также будет размещен во флеше.


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


У gcc есть атрибут section(".init"), помечая им сишную функцию можно заставить ее вызываться в начале выполнения программы, для чего используется тот же механизм, что и для конструкторов, т.е. типичный gcc стартап для С и С++ ничем не отличается. Естественно атрибут эмуллирующий деструкторы имеется тоже.


Семисегментник, где-то внутри класса есть такой код:

Насколько тривиально на С все размудрить для таких списков пинов?

Пины от реальной платки которая втыкается в разъем для LTDC

В IAR и Keil стартап по ResetHandler передаёт управление стандартной библиотеке. Она сама знает есть ли конструкторы и вызывает их. В GCC у большинства стандартных стартапов точно так же передаётся в __libc_init_array(); И лишь немногие используют ключ "-nostartfiles" и заменяют её двумя строчкамиПри том что у подавляющего большинства стартап вообще на asm и они туда никогда не заглядывали. И он из коробки всё это поддерживает. Так что, вопрос яйца выеденного не стоит.

Ничуть не больше чем на Си.

А на плюсах нетривиально? На каком языке написано? Надо смотреть дамп, чтобы сказать во что это компилируется? Мне нет.

Заберите их себе. Чем HAL-воды в этом плане лучше?

А почему должно быть иначе, если вы не знаете язык?

Добавлено after 1 hour 46 minutes 42 seconds:
Сообщением выше Reflector показал простую оптимизацию, которая без C++17 не работает.

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

Спойлер

Код:

const int arr[] = { 20, 40, 10, 50, 30 };

template<const auto& Arr>
struct Transform
{
   constexpr Transform()
   {
      std::copy(Arr, std::end(Arr), arr);
      std::sort(arr, std::end(arr));
   }

   int arr[std::size(Arr)]{};
};

constexpr Transform<arr> trfm;

for(auto& v: trfm.arr)
{
   rtt.print<"{}, {}\n">(&v, v);
}

С выключенной оптимизацией(с включенной тем более) следующий код дает абсолютно идентичный бинарник:

В первом случае в конструкторе вызываются две стандартных функции, насколько они тяжелые можно понять заменив в одной стоке constexpr, которого все равно в С нет, на const:

Теперь имеем плюс 20 байт RAM, т.к. массив стал хранится именно там, и плюс 3КБ кода во флеше(для -O0), или +770 байт для -O2.

Небольшая ремарочка к предыдущему сообщению. Тут уже без С++20 не обойтись

Ну не маньяки ли?
Сишники как писали с 70-х годов на С, так и пишут. С минимальнейшими изменениями (но можно и вообще без изменений, в том же духе писать; и ничего, gcc соберет).
А вот крестовикам делать нехер, только каждые несколько лет считай заново новый ЯП учить!
С тем и хорош, что практически "надстройка над ассемблером". Очень простой язык (чуть сложней ассемблера, зато писанины поменьше, но при этом остается понимание). А С++ — это вообще дичь лютая!