@warzone Zarówno C jak i C++ to języki konstruowane według zasad "nie płacisz za to z czego nie korzystasz". To znaczy, że z jednej strony są bardzo wydajne (nie robią nic ponad to o co je poprosisz), a z drugiej możesz sobie stworzyć pusty pointer i wskazuje on na losowy adres pamięci. Inicjalizacja takiego pointera przez kompilator to praca której nie wszyscy potrzebują i tyle .
Z C++ w embedded jest problem jak z piłami łańcuchowymi. Ekstremalnie skutecznie przecinają zarówno drewno jak i kończyny. Nieprzeszkolony operator szybko się potnie przez co łatwo powiedzieć, że "ręczna piła dużo lepsza bo jeszcze nic sobie nią nie uciąłem".
Niestety ani uczelnie ani podręczniki nie skupiają się na np. tym jak malloc/new, free/delete, biblioteka standardowa itp. działają pod maską i niemal wszyscy jesteśmy tymi nieprzeszkolonymi operatorami. Śledzenie pamięci i jej fragmentacji mogłoby zjeść pół miejsca na kod w takim MCU z 32kB flesha i często free() nawet nie jest zaimplementowane...
Ja mam zasady które stosuje po kolei w zależności od konieczności:
-
alokuj tylko statycznie (95% przypadków)
-
jak się nie da alokuj dynamicznie ale dokładnie RAZ (np. w zależności od konfiguracji urządzenia jeden bufor może być większy, a drugi mniejszy. Alokuje je na starcie i nie ruszam.
-
alokuj dynamicznie chunki ale tylko o jednej z 1..n znanej wielkości. Wtedy sensownie łatwo jest zaimplementować śledzenie fragmentacji. Koszty testów takiego oprogramowania to od razu x2 albo x3.