Czy jest jakiś powód, aby używać C zamiast C++ do tworzenia embedded?

Dla bardzo ograniczonego zasobem celu, takiego jak 4KB pamięci RAM, chciałbym przetestować wody z kilkoma próbkami przed podjęciem dużo wysiłku, który nie może być łatwo przeniesiony z powrotem do czystej implementacji ANSI C.

W środowisku wbudowanym, naprawdę trzeba uważać na alokację pamięci. Aby wyegzekwować tę opiekę, może być konieczne zdefiniowanie globalnego operator new() i jego przyjaciół do czegoś, czego nie można nawet powiązać, aby wiedzieć, że nie jest używany. Z drugiej strony umieszczenie new jest prawdopodobnie twoim przyjacielem, gdy jest używane rozsądnie wraz ze stabilnym, bezpiecznym dla wątków i gwarantowanym systemem alokacji opóźnień.

Inlined funkcje nie sprawią większego problemu, chyba że są na tyle duże, że powinny być prawdziwymi funkcjami. Oczywiście makra ich zastąpienie miało ten sam problem.

Szablony również nie mogą powodować problemów, chyba że ich instancja zacznie działać w amoku. W przypadku dowolnego szablonu, którego używasz, sprawdź wygenerowany kod (Mapa linków może mieć wystarczające wskazówki), aby upewnić się, że wystąpiły tylko instancje, których zamierzałeś użyć.

Innym problemem, który może się pojawić, jest kompatybilność z Twoim debuggerem. Nie jest niczym niezwykłym, że debugger sprzętowy może mieć bardzo ograniczone wsparcie dla interakcji z oryginalnym kodem źródłowym. Jeśli faktycznie musisz debugować w assembly, to ciekawa nazwa mangling C++ może dodać dodatkowe zamieszanie do zadania.

RTTI, dynamiczne odlewy, wielokrotne dziedziczenie, ciężki polimorfizm i wyjątki wiążą się z pewnym kosztem czasu ich użycia. Kilka z tych funkcji, które kosztują w całości program, jeśli są używane, inni po prostu zwiększają wagę klas, które ich potrzebują. Poznaj różnicę i mądrze wybieraj zaawansowane funkcje z pełną znajomością co najmniej pobieżnej analizy kosztów/korzyści.

W małym środowisku wbudowanym będziesz albo łączył się bezpośrednio z jądrem czasu rzeczywistego, albo działał bezpośrednio na sprzęcie. Tak czy inaczej, musisz upewnić się, że Twój kod uruchamiania uruchomieniowego obsługuje poprawnie zadania związane z uruchomieniem C++. To może być tak proste, jak upewnij się, że używasz odpowiednich opcji łącznika, ale ponieważ często ma się bezpośrednią kontrolę nad źródłem do punktu wejścia resetowania zasilania, może być konieczne sprawdzenie tego, aby upewnić się, że robi wszystko. Na przykład na platformie ColdFire, nad którą pracowałem, narzędzia dev dostarczano z CRT0.Moduł S, który miał obecne inicjalizatory C++, ale komentował. Gdybym użył go prosto z pudełka, byłbym zdziwiony globalnymi obiektami, których konstruktorzy nigdy nie uruchomili w wszystkie.

Również w środowisku wbudowanym często konieczne jest zainicjowanie urządzeń sprzętowych, zanim będą mogły być używane, a jeśli nie ma systemu operacyjnego ani boot loadera, to robi to Twój kod. Należy pamiętać, że konstruktory dla obiektów globalnych są uruchamiane przed main() jest wywołany, więc będziesz musiał zmodyfikować swój lokalny CRT0.S (lub jego odpowiednik) aby wykonać inicjalizację sprzętową przed, wywoływane są same konstruktory globalne. Oczywiście, koniec main() jest za późno.

Nie. Każda z funkcji języka C++, która może powodować problemy (polimorfizm runtime, RTTI, itp.) można uniknąć podczas tworzenia wbudowanego. Jest społeczność programistów embedded C++ (pamiętam, że czytałam kolumny programistów embedded korzystających z C++ w starym Dzienniku użytkowników C / C++) i nie wyobrażam sobie, żeby byli bardzo głośni, gdyby wybór był taki zły.

The Technical Report on C++ Performance jest świetnym przewodnikiem po tego typu rzeczach. Zauważ, że zawiera sekcję dotyczącą zagadnień programowania wbudowanego!

Również ++ na wzmiankę o Embedded C++ w odpowiedziach. Standard nie jest w 100% do moich gustów, ale jest dobrym punktem odniesienia przy podejmowaniu decyzji, które części C++ można upuścić.

Podczas programowania dla małych platform wyłączamy wyjątki i RTTI, unikamy Wirtualnego dziedziczenia i zwracamy szczególną uwagę na liczbę wirtualnych funkcji, które mamy w pobliżu.

Twój znajomy jest jednak mapą linkera: sprawdzaj ją często, a szybko zauważysz źródła kodu i statyczną pamięć.

Następnie obowiązują standardowe zasady wykorzystania pamięci dynamicznej: w środowisku tak ograniczonym jak to, o którym wspominasz, możesz w ogóle nie używać alokacji dynamicznych. Czasami można uniknąć pul pamięci dla małych dynamicznych alokacji lub alokacji "opartej na klatkach", w których wstępnie przydzielany jest blok i wyrzuć wszystko później.

Zalecam korzystanie z kompilatora C++, ale ograniczam korzystanie z specyficznych funkcji C++. Możesz programować jak C w C++ (środowisko uruchomieniowe C jest włączone podczas wykonywania C++, choć w większości aplikacji wbudowanych i tak nie korzystasz z biblioteki standardowej).

Możesz śmiało korzystać z klas C++ itp., just

• Ogranicz korzystanie z funkcji wirtualnych (jak już powiedziałeś)
• Ogranicz korzystanie z szablonów
• dla wbudowanej platformy, będziesz chciał zastąpić operatora new i / lub użyj nowego miejsca do alokacji pamięci.

Jako inżynier firmware / embedded system, mogę wam powiedzieć, dlaczego C jest nadal #1 Wybór NAD C++ i tak, jestem biegły w obu z nich.

1) Niektóre cele, które rozwijamy mają 64kB PAMIĘCI RAM zarówno dla kodu, jak i danych, więc musisz się upewnić, że każdy bajt się liczy, i tak, miałem do czynienia z optymalizacją kodu, aby zaoszczędzić 4 bajty, które kosztowały mnie 2 godziny, i to w 2008 roku.

2) Każda funkcja biblioteki C jest sprawdzana przed umieszczeniem jej w kodzie końcowym, ze względu na rozmiar ograniczenia, więc wolimy, aby ludzie nie używali divide (nie ma dzielnika sprzętowego, więc potrzebna jest duża biblioteka), malloc (ponieważ nie mamy sterty, cała pamięć jest alokowana z bufora danych w 512 bajtowym kawałku i musi być sprawdzana w kodzie), lub innych praktyk zorientowanych obiektowo, które niosą ze sobą duże kary. Pamiętaj, że liczą się wszystkie używane funkcje biblioteczne.

3) słyszałeś kiedyś o pojęciu nakładka? masz tak mało miejsca na kod, że czasami musisz zamienić rzeczy na inny zestaw kodu. Jeśli zadzwonisz funkcja biblioteczna wtedy funkcja biblioteczna musi być rezydentna. Jeśli używasz go tylko w funkcji nakładki, marnujesz dużo miejsca polegając na zbyt wielu obiektowych metodach. Więc nie zakładaj żadnej funkcji biblioteki C, nie mówiąc już o C++ do zaakceptowania.

4) Odlewanie, a nawet pakowanie (gdzie struktura danych przekracza granicę słowa) są potrzebne ze względu na ograniczoną konstrukcję sprzętową (tj. silnik ECC, który jest podłączony w określony sposób) lub aby poradzić sobie z błędem sprzętowym. Nie można zakładać zbyt wiele inplicite, więc dlaczego obiekt orientować go zbyt dużo?

5) najgorszy scenariusz: wyeliminowanie niektórych metod obiektowych zmusi developera do zastanowienia się, zanim użyją zasobów, które mogą eksplodować (np. przydzielając 512bajtów na stosie, a nie z bufora danych), i uniemożliwi niektóre z potencjalnych najgorszych scenariuszy, które nie są testowane lub eliminują całą ścieżkę kodu razem.

6) używamy wielu abstrakcji, aby zachować sprzęt z oprogramowania i uczynić kod przenośnym jak to możliwe i przyjazne dla symulacji. Dostęp sprzętowy musi być zawinięty w MAKRO lub funkcję wbudowaną, które są warunkowo kompilowane między różnymi platformami, typ danych musi być zapisany jako rozmiar bajtów, a nie specyficzny dla celu, użycie wskaźnika bezpośredniego nie jest dozwolone (ponieważ niektóre platformy zakładają, że zmapowane We/Wy pamięci są takie same jak pamięć danych), itd.

Mogę wymyślić więcej, ale masz pomysł. Amerykańskie firmware mają szkolenie zorientowane obiektowo, ale zadanie wbudowanego systemu może być tak zorientowany sprzętowo i niski poziom, że nie jest wysoki poziom lub abstrakcyjny z natury.

BTW, każda praca z firmware, w której byłem używa kontroli źródła, Nie wiem skąd ten pomysł.

- jakiś firmware z Sandiska.

Moje osobiste preferencje to C ponieważ:

• wiem, co robi każda linijka kodu (i kosztuje)
• nie znam C++ na tyle dobrze, aby wiedzieć, co robi każda linijka kodu (i kosztuje)

Na przykład, co asm daje to niewinne stwierdzenie:

a[i] = b[j] * c[k];

CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP

Liczba wyprodukowanych instrukcji zależy od:

• Rozmiary a, b I c.
• czy te wskaźniki są przechowywane na stosie czy są globalne
• czy ja, j I k są na stosie czy są globalne

Jest to szczególnie prawdziwe w małym świecie wbudowanym, gdzie procesory nie są po prostu skonfigurowane do obsługi C. więc moja odpowiedź brzmiałaby, że C i C++ są tak samo złe jak każdy inne, chyba że zawsze sprawdzasz wyjście asm, w którym to przypadku są one tak samo dobre jak siebie nawzajem.

Hugo

Słyszałem, że niektórzy ludzie wolą C do pracy wbudowanej ze względu na to, że jest prostszy, a tym samym łatwiej przewidzieć rzeczywisty kod, który zostanie wygenerowany.

Osobiście uważam, że pisanie C-style c++ (używanie szablonów dla bezpieczeństwa typu) da Ci wiele korzyści i nie widzę żadnego prawdziwego powodu, aby tego nie robić.

Nie widzę powodu, aby używać C zamiast c++. Cokolwiek można zrobić w C, można to zrobić również w C++. Jeśli chcesz uniknąć kosztów ogólnych VMT, nie używaj metod wirtualnych i polimorfizmu.

Jednak C++ może dostarczyć kilka bardzo przydatnych idiomów bez zbędnych kosztów. Jednym z moich ulubionych jest RAII. Klasy nie są konieczne drogie pod względem pamięci lub wydajności...

Napisałem kod do ARM7 embedded paltform na IAR Workbench. Gorąco polecam poleganie na szablonach do optymalizacji czasu kompilacji i przewidywania ścieżki. Unikaj dynamicznego rzucania jak plaga. Używaj cech/zasad na swoją korzyść, zgodnie z opisem w książce Andrei Alexandrescu, Modern C++ design .

Wiem, że może być ciężko się tego nauczyć, ale jestem również pewna, że twój produkt skorzysta na takim podejściu.

Dobrym powodem, a czasami jedynym powodem jest to, że wciąż nie ma kompilatora C++ dla konkretnego systemu wbudowanego. Tak jest na przykład w przypadku mikroprocesorów PIC. Są bardzo łatwe do napisania i mają darmowy kompilator C (właściwie niewielki wariant C), ale nie ma kompilatora C++ w zasięgu wzroku.

Dla systemu ograniczonego do 4K ram, użyłbym C, a nie c++, tylko po to, abyś mógł mieć pewność, że widzisz wszystko, co się dzieje. Rzecz z C++, jest to, że jest bardzo łatwy w użyciu znacznie więcej zasobów (zarówno CPU jak i pamięci) niż to wygląda patrząc na kod. (Oh, po prostu stworzę kolejny BlerfObject, aby to zrobić...UPS! z pamięci!)

Możesz to zrobić w C++, jak już wspomniano (bez RTTI, bez vtables, itp, itp), ale poświęcisz tyle czasu, aby upewnić się, że użycie C++ nie odczep się od siebie tak, jak byś zrobił odpowiednik w C.

Ludzki umysł zajmuje się złożonością, oceniając jak najwięcej, a następnie decydując, na czym należy się skupić, i odrzucając lub deprecjonując resztę. To jest cała podstawa brandingu w marketingu i w dużej mierze ikony.

Aby zwalczyć tę tendencję wolę C od C++, ponieważ zmusza to do myślenia o kodzie i o tym, jak wchodzi on w interakcję ze sprzętem bliżej - nieubłaganie blisko.

Z wieloletniego doświadczenia wynika, że C zmusza wymyślanie lepszych rozwiązań problemów, po części przez zejście z drogi i nie zmuszanie do marnowania czasu na zaspokajanie ograniczeń, które niektórzy kompilatorzy uznali za dobry pomysł, lub zastanawianie się, co się dzieje "pod przykrywką".

W tym duchu, języki niskiego poziomu, takie jak C, spędzają dużo czasu skupiając się na sprzęcie i budowaniu dobrych pakietów struktury danych/algorytmów, podczas gdy języki wysokiego poziomu spędzają dużo czasu, zastanawiając się co się tam dzieje i dlaczego nie można zrobić czegoś całkowicie rozsądnego w konkretnym kontekście i środowisku. Pokonanie kompilatora do poddania się (mocne pisanie jest najgorszym przestępcą) nie jest produktywnym wykorzystaniem czasu.

Pewnie dobrze pasuję do formy programisty - Lubię sterowanie. Moim zdaniem to nie jest wada osobowości programisty. Płacą nam za kontrolę. Dokładniej, bezbłędna Kontrola. C daje dużo większą kontrolę niż C++.

OsobiĹ "cie z 4KB pamiÄ ™ ci powiedziaĹ' bym, Ĺźe nie ma wiÄ ™ kszego przebiegu w C++, wiÄ ™ c po prostu wybierz ten, ktĂłry wydaje siÄ ™ najlepszym zestawieniem kompilatora/runtime dla tego zadania, poniewaĹź jÄ ™ zyk prawdopodobnie nie bÄ ™ dzie znaczÄ ... cy.

Zauważ, że i tak nie chodzi tylko o język, ponieważ liczy się również biblioteka. Często biblioteki C mają nieco mniejszy minimalny rozmiar, ale mogę sobie wyobrazić, że biblioteki C++ ukierunkowane na rozwój wbudowany są zmniejszone, więc pamiętaj, aby przetestować.

Niektórzy mówią, że kompilatory C mogą generować znacznie wydajniejszy Kod, ponieważ nie muszą obsługiwać zaawansowanych funkcji C++, a zatem mogą być bardziej agresywne w swoich optymalizacjach.

Oczywiście w tym przypadku warto przetestować te dwa specyficzne Kompilatory.

C wygrywa na przenośności-ponieważ jest mniej niejednoznaczny w specyfikacji języka; dlatego oferuje znacznie lepszą przenośność i elastyczność w różnych kompilatorach itp. (mniej bólów głowy).

Jeśli nie zamierzasz wykorzystać funkcji C++, aby zaspokoić potrzeby, przejdź do C.

Czy widzisz jakiś powód, aby trzymać się C89 przy rozwijaniu bardzo ograniczonych hardware(4KB RAM)?

Osobiście, jeśli chodzi o aplikacje wbudowane (Kiedy mówię embedded, nie mam na myśli winCE, iPhone itp.. nadęte urządzenia wbudowane dzisiaj). Mam na myśli urządzenia ograniczające zasoby. Wolę C, choć z C++ też sporo pracowałem.

Na przykład urządzenie, o którym mówisz ma 4KB pamięci RAM, dobrze tylko z tego powodu nie chciałbym rozważ C++. Oczywiście, możesz być w stanie zaprojektować coś małego za pomocą C++ i ograniczyć jego użycie w swojej aplikacji, jak sugerowały inne posty, ale C++ "może" potencjalnie skończyć się komplikacją/wzdęciem aplikacji pod pokrywami.

Zamierzasz połączyć statycznie? Możesz chcieć porównać statyczną aplikację atrapy przy użyciu c++ vs c. może to prowadzić do rozważenia C zamiast. Z drugiej strony, jeśli jesteś w stanie zbudować aplikację C++ zgodnie z wymaganiami pamięci, przejdź za to.

IMHO, Ogólnie rzecz biorąc, w aplikacjach wbudowanych lubię wiedzieć wszystko, co się dzieje. Kto korzysta z pamięci / zasobów systemowych, ile i dlaczego? Kiedy ich uwolnią?

Przy rozwijaniu dla celu Z X ilością zasobów, procesora, pamięci itp.. Staram się pozostać na dolnej stronie korzystania z tych zasobów, ponieważ nigdy nie wiadomo, jakie przyszłe wymagania pojawią się w ten sposób, że dodasz więcej kodu do projektu, który miał być prostą małą aplikacją ale staje się o wiele większy.

Mój wybór jest zwykle określany przez Bibliotekę C, której używamy, która jest wybierana na podstawie tego, co urządzenie musi zrobić. Czyli 9/10 razy .. kończy się na uclibc lub newlib i C. jądro, którego używamy, również ma duży wpływ na to, lub jeśli piszemy własne jądro.

To także wybór wspólnej płaszczyzny. Większość dobrych programistów C nie ma problemu z używaniem C++ (choć wielu cały czas narzeka, że go używają).. ale nie znalazłem odwrotności do prawdy (w moim doświadczenie).

W projekcie, nad którym pracujemy (który obejmuje od podstaw jądro), większość rzeczy odbywa się w C, jednak mały stos sieciowy został zaimplementowany w C++, ponieważ implementacja sieci przy użyciu C++była po prostu łatwiejsza i mniej problematyczna.

Efekt końcowy jest taki, że urządzenie albo zadziała i przejdzie testy akceptacyjne, albo nie. jeśli możesz zaimplementować Foo w XX stosie i YY stosie przy użyciu języka z, użyj tego, co sprawia, że jesteś bardziej produktywny.

My preferencje osobiste to C ponieważ:

• wiem, co robi każda linijka kodu (i kosztuje)
• nie znam C++ na tyle dobrze, aby wiedzieć, co robi każda linijka kodu (i kosztuje)

Tak, jestem zadowolony z C++, ale nie znam go tak dobrze jak Standard C.

Teraz, jeśli możesz powiedzieć odwrotnie, cóż, użyj tego, co wiesz:) jeśli to działa, przechodzi testy itp .. w czym problem?

Ile masz ROM / FLASH?

4kB pamięci RAM może nadal oznaczać, że istnieją setki kilobajtów pamięci FLASH do przechowywania rzeczywistego kodu i danych statycznych. PAMIĘĆ RAM w tej wielkości jest przeznaczona tylko dla zmiennych, a jeśli będziesz z nimi ostrożny, możesz zmieścić do pamięci dość duży program pod względem linii kodu.

Jednak C++ utrudnia umieszczanie kodu i danych we flashu, ze względu na reguły budowy obiektów w czasie wykonywania. W C można łatwo umieścić stałą strukturę do pamięci FLASH i dostęp do niej jako sprzętowo-stały obiekt. W C++, stały obiekt wymagałby kompilatora do oceny konstruktora w czasie kompilacji, co moim zdaniem jest wciąż ponad to, co może zrobić kompilator C++ (teoretycznie można to zrobić, ale w praktyce jest to bardzo trudne).

Więc w środowisku typu "mały RAM", "duży FLASH" wybrałbym C lada dzień. Zauważ, że dobry pośredni wybór i C99 który ma większość ładnych funkcji C++ dla kod nieklasowy.

Ogólnie nie C++ jest super zestawem C. byłoby to szczególnie prawdziwe dla nowych projektów.

Jesteś na dobrej drodze w unikaniu konstrukcji C++, które mogą być drogie pod względem czasu procesora i pamięci.

Zauważ, że niektóre rzeczy, takie jak polimorfizm mogą być bardzo cenne - są zasadniczo wskaźnikami funkcji. Jeśli okaże się, że ich potrzebujesz, używaj ich-mądrze.

Również dobra (dobrze zaprojektowana) obsługa wyjątków może sprawić, że wbudowana aplikacja będzie bardziej niezawodna niż aplikacja, która obsługuje rzeczy z tradycyjnymi kodami błędów.

Jedynym powodem, aby preferować C IMHO byłoby, jeśli kompilator C++ dla Twojej platformy nie jest w dobrym stanie(buggy, słaba optymalizacja, itp).

Książka C++ dla programistów gier zawiera informacje o tym, kiedy Rozmiar kodu wzrośnie w oparciu o funkcje z C++.

Masz inline w C99. Może lubisz ctors, ale sprawa poprawienia dtors może być brudna. Jeśli jedynym powodem, aby nie używać C, są przestrzenie nazw, naprawdę trzymałbym się C89. Dzieje się tak, ponieważ możesz chcieć przenieść go na nieco inną wbudowaną platformę. Możesz później zacząć pisać w C++ na tym samym kodzie. Ale uważaj na poniższe, gdzie C++ nie jest supersetem C. wiem, że mówiłeś, że masz kompilator C89, ale czy to porównanie C++ z C99 i tak, jako pierwszy item for example is true for any C since K & R.

Sizeof ' a ' > 1 w C, a nie w C++. W C masz tablice zmiennej długości VLA. Przykład: func (int i) {int a [i] . W C masz zmienne vam członków tablicy. Przykład: struct{int b; int m[];}.

Chcę tylko powiedzieć, że nie ma systemu z "nieograniczonymi" zasobami. Wszystko na tym świecie jest ograniczone i każda aplikacja powinna rozważyć wykorzystanie zasobów bez względu na to, czy jego ASM, C, JAVA lub JavaScript. Manekiny, które przydzielają kilka Mbs "dla pewności", sprawiają, że iPhone 7, Pixel i inne urządzenia są niezwykle luggy. Bez względu na to, czy masz 4kb, czy 40 Gb.

Ale z innej strony przeciwstawianie się marnowaniu zasobów - to czas, który zajmuje oszczędzanie tych zasobów. Jeśli zajmie to 1 tydzień extra napisać prostą rzecz w C, aby zapisać kilka kleszczy i kilka bajtów zamiast używać C++ już zaimplementowane, przetestowane i rozproszone. Po co się trudzić? To jak zakup koncentratora usb. tak, możesz zrobić to sam, ale czy będzie lepiej? bardziej wiarygodny? taniej, jeśli liczyć swój czas?

Po prostu myśl boczna - nawet moc z gniazdka nie jest nieograniczona. Spróbuj zbadać, skąd pochodzi, a zobaczysz głównie jego od spalenia czegoś. Prawo energetyczne i materialne jest nadal aktualne: żaden materiał ani energia nie pojawia się ani nie znika, lecz raczej przekształca się.

W przypadku problemu z alokacją pamięci, mogę polecić użycie platformy kwantowej i jej podejścia maszyny stanowej, ponieważ przydziela ona wszystko, czego potrzebujesz w czasie inicjalizacji. Pomaga również złagodzić problemy sporne.

Ten produkt działa zarówno w C jak i C++.

To zależy od kompilatora.

Nie wszystkie wbudowane Kompilatory implementują cały C++, a nawet jeśli tak, mogą nie być dobre w unikaniu nadcięcia kodu (co jest zawsze ryzykiem w przypadku szablonów). Przetestuj go za pomocą kilku mniejszych programów, sprawdź, czy nie napotkasz żadnych problemów.

Ale biorąc pod uwagę dobry kompilator, nie, nie ma powodu, aby nie używać C++.

Właśnie znalazłem przykład, jak używać ISO C++ do wbudowanego programowania, który może być interesujący dla kogoś, kto podejmuje decyzję, gdy używasz C++ lub C.

Został dostarczony przez Bjarne Stroustrup na jego stronie głównej :

Aby dowiedzieć się, jak ISO C++ może być używany do programowania poważnych systemów wbudowanych, zobacz JSF air vehicle C++ coding standards .

Inna odpowiedź posta na inny aspekt pytania:

"malloc"

Niektóre poprzednie odpowiedzi mówią sporo na ten temat. Dlaczego myślisz, że ten telefon istnieje? W przypadku naprawdę małej platformy malloc wydaje się być niedostępny lub zdecydowanie opcjonalny. Implementacja dynamicznej alokacji pamięci wydaje się mieć sens, gdy masz RTO w dolnej części systemu - ale do tego czasu jest to czysto niebezpieczne.

Można zajść bardzo daleko bez niego. Tylko pomyśl o wszystkich starych programach FORTRAN, które nie miały nawet odpowiedniego stosu dla zmiennych lokalnych...

Na tak ograniczonym systemie. Po prostu idź do asemblera. Daje całkowitą kontrolę nad każdym aspektem i nie daje żadnych kosztów.

Prawdopodobnie też dużo szybciej, ponieważ wiele wbudowanych kompilatorów nie jest najlepszymi optymalizatorami (zwłaszcza jeśli porównamy je do najnowocześniejszych kompilatorów, takich jak te, które mamy na pulpit (intel, visual studio, itp.))

"Tak, Tak...ale c jest wielokrotnego użytku i...". Na tak ograniczonym systemie, są szanse, że nie będziesz ponownie używać dużo tego kodu na innym systemie w każdym razie. W tym samym systemie asembler jest tak samo możliwy do ponownego użycia.