Всем привет. Если я буду писать код на С++ для

контроллеров, то какие подводные камни меня ожидают? Всю жизнь пишу на чистом си, но думаю мож зря я так и современные компиляторы не рождают мамонтов. Речь идет про труевые плюсы с перегрузками, классами, шаблонами и прочий плюсовый "треш". Еще в голове не уживается то, что куча библиотек на чистом си написана. Тот же фрииртос как себя будет чувствовать с плюсами?

Я ненастоящий сварщик, а так, любитель. Поэтому про то, что знаю/слышал. Проблемы обычно начинаются там, где начинается динамическое выделение памяти. В основном потому, что RAM мало. Поэтому все стандартные функции, использующие динамику есть смысл избегать. Также и во фриртос, есть смысл использовать статическую модель, если можно обойтись без динамики. Шаблоны - норм вариант. У меня есть ощущение, что они раздувают флэш, правда это только ощущение. Но время компиляции по сравнению с СИ точно увеличится. Ещё будут всякие неочевидные штуки, связанные с тем, что языки разные. Там из-за ссылок или инициализации по умолчанию, наличия конструкторов. Фриртос нормально работает. Приходится цпп оборачивать в extern C. Поскольку я пишу редко понемногу и для себя, то с проблемами почти не сталкиваюсь. И в принципе могу себе позволить стандартный printf или string. Но понимаю, что большой проект может не влезть в камень из-за таких вольностей. Поэтому функции вывода в основном самописные, cstring и редко sprintf. Вообще, когда на плюсах удобнее и приятнее. Но в при таких ограничениях получается, что это просто си с классами, шаблонами, итераторами, lambda, inline, constexpr и auto. Хотя есть примеры, где плюсы в полный рост и всё работает. Мне один программист утверждал, что под МК он писал такой же c++, как сейчас пишет в амазоне. Не верю. Мб поэтому за ним всё переписали :).

Для фриртоса на гите свободно ищутся врапперы.плюсы хороши,когда проект большой,и много разных структур данных.к слову,есть etl,которая сделана на статике.для 8 битных камней все это не имеет особого смысла,а для 32 битных-вполне себе применяемо

Проблемы работы с динамической памятью в МК не столько в том, что ее мало, сколько в контроле ее использования. Важно не допустить переполнения и фрагментации. Если хочется уверенности в том, что контроллер не использует динамическую память, или очень хочется усилить контроль, можно перегрузить new/delete и прилинковать к проекту свой malloc/free. Проекты, которые используют только статическую память, хороши тем, что уже на этапе компиляции есть 100% уверенность в том, что проект влез в камень. Насколько это нужно в каждом конкретном случае - второй вопрос. При острой нехватке оперативной памяти мы вполне можем захотеть разделить ее между несколькими пользователями. Каждое инстанцирование шаблона класса в класс требует памяти для хранения кода этого класса. Это нормально, у нас же цель сделать нашу же работу чуть удобнее, а не с экономить несколько сот байт флешки :). В конце концов, большому проекту - большой камень. С код отлично работает в С++ приложениях. С++ позволяет лучше изолировать код за счет классов. А с хорошо изолированным кодом гораздо приятнее работать. Начиная с того, что бизнес-логику приложения можно со 100% гарантией оторвать от конкретной платы и переиспользовать ее во всех нужных местах, заканчивая покрытия кода тестами. Еще из плюсов стоит добавить стандартную библиотеку шаблонов или ее аналог, которая, при правильном использовании, позволяет не городить велосипеды для стандартных контейнеров и алгоритмов. Получилось немного скомкано, но тема довольно большая. На хабре есть пара хороших статей про то, как правильно прикрутить С++ к проекту для микроконтроллеров.

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

Все верно, это никакое не отличие :) Это больше про стандартные библиотеки.

Если выпилить богопротивное RTTI и исключения, то плюсы вполне ок