Gibt es einen Grund zu verwenden C anstelle von C ++ für Embedded-Entwicklung?
https://stackoverflow.com/questions/812717
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Frage
Ich habe zwei Compiler auf meiner Hardware C ++ und C89
Ich denke über C ++ mit Klassen, aber ohne Polymorphismus (vtables zu vermeiden). Die wichtigsten Gründe, warum ich möchte C ++ verwenden sind:
- Ich ziehe „inline“ Funktionen anstelle von Makrodefinitionen zu verwenden.
- Ich möchte Namensraum verwenden, wie ich Krempel den Code Präfixe.
- Ich sehe C ++ ein bisschen Typ sicherer vor allem wegen der Vorlagen und die ausführliche Guss.
- Ich mag überladene Funktionen und Konstrukteure (für automatische Gießen verwendet wird).
Sehen Sie irgendeinen Grund mit C89 zu bleiben, wenn für sehr begrenzte Hardware (4 KB RAM) zu entwickeln?
Fazit
Vielen Dank für Ihre Antworten, sie waren sehr hilfreich!
dachte ich das Thema durch und ich werde dabei bleiben C vor allem, weil:
- Es ist einfacher eigentliche Code in C vorherzusagen, und das ist wirklich wichtig, wenn Sie nur 4 KB RAM.
- Mein Team hauptsächlich aus C-Entwickler besteht, so erweiterte C ++ Funktionen werden nicht häufig verwendet werden.
- Ich habe einen Weg, um Inline-Funktionen in meinen C-Compiler (C89) gefunden.
Es ist schwer, eine Antwort zu akzeptieren, wie man so viele gute Antworten zur Verfügung gestellt. Leider kann ich nicht ein Wiki erstellen und akzeptieren, so werde ich eine Antwort auswählen, die mich am meisten denken gemacht.
Lösung
Zwei Gründe für die Verwendung von C über C ++:
- Für viele Embedded-Prozessoren, entweder gibt es keine C ++ Compiler, oder man muss dafür extra zahlen.
- Meine Erfahrung ist, dass ein signficant Anteil von Embedded-Software-Ingenieure haben wenig oder keine Erfahrung mit C ++ - entweder wegen (1), oder weil es nicht gelehrt werden auf elektronischen Engineeering Grad neigt - und so wäre es besser, Stick mit dem, was sie kennen.
Auch die ursprüngliche Frage, und eine Reihe von Kommentaren, erwähnen die 4 Kb von RAM . Für einen typischen Embedded-Prozessor, ist die Menge an RAM (meistens) in keinen Zusammenhang mit der Code-Größe, wie der Code gespeichert ist, und führen Sie aus, Blitz.
Sicherlich ist die Menge an Code Speicherplatz etwas im Auge zu behalten, aber wie neu, geräumigeren, Prozessoren auf dem Markt erscheinen, es ist weniger ein Problem, als es für alle, aber die meist kostensensitive Projekte verwendet werden sollte .
Auf der Verwendung einer Teilmenge von C ++ für die Verwendung mit Embedded-Systemen: Es gibt jetzt ein MISRA C ++ Standard, der einen Blick wert sein kann.
EDIT: Siehe auch diese Frage , die zu einer Debatte über C vs C ++ führte für eingebettete Systeme.
Andere Tipps
Für eine sehr ressourcenbeschränkten Ziel wie 4 KB RAM, würde ich das Wasser mit einigen Proben testen, bevor viel Mühe zu begehen, die nicht leicht wieder in einer reinen ANSI-C-portiert werden können Implementierung.
Die Embedded C ++ Arbeitsgruppe hat eine Standard-Teilmenge der Sprache und eine Standardteilmenge der Standardbibliothek mit ihm zu gehen vorzuschlagen. Ich verlor diese Bemühungen, wenn das C Benutzerhandbuch Journal gestorben, leider. Es sieht aus wie ein Artikel unter Wikipedia ist, und dass die Ausschuss noch existiert.
In einer eingebetteten Umgebung, müssen Sie wirklich über Speicherzuweisung vorsichtig sein. Um diese Pflege zu erzwingen, müssen Sie möglicherweise die globale operator new() und seine Freunde, um etwas definieren, die nicht einmal verknüpft werden, so dass Sie wissen, dass es nicht verwendet wird. Placement new auf der anderen Seite ist wahrscheinlich deinen Freund sein, wenn umsichtig zusammen mit einem stabilen, Thread-sicher verwendet und Latenz-Zuordnungsschema garantiert.
inlined Funktionen nicht viel Problem verursachen, es sei denn, sie groß genug sind, dass sie wahr Funktionen in erster Linie sein sollte. Natürlich sind die Makros ihr das gleiche Problem hatte zu ersetzen.
Vorlagen Auch verursachen kein Problem, es sei denn, ihre Instanziierung Amok läuft. Für jede Vorlage, die Sie Ihren generierten Code nicht verwenden, prüfen (der Link Karte genügend Anhaltspunkte haben kann), um sicherzustellen, dass nur die instantiations Sie zufällig Gebrauch bestimmt.
Ein weiteres Problem, das ist die Kompatibilität mit Ihrem Debugger auftreten kann. Es ist nicht ungewöhnlich für einen ansonsten verwendbaren Hardware-Debugger für die Interaktion mit dem ursprünglichen Quellcode sehr begrenzte Unterstützung zu haben. Wenn Sie effektiv bei der Montage debuggen müssen, dann ist der interessanten Namen Mangeln von C ++ können zusätzliche Verwirrung, um die Aufgabe hinzuzufügen.
RTTI, dynamische Casts, Mehrfachvererbung, schwerer Polymorphismus und Ausnahmen alle mit einem gewissen Menge an Laufzeit Kosten für ihren Einsatz kommen. Einige dieser Merkmale Ebene, die über das gesamte Programm kosten, wenn sie verwendet werden, andere erhöhen nur das Gewicht von Klassen, die sie benötigen. Kennen Sie den Unterschied, und wählen Sie erweiterte Funktionen weise mit voller Kenntnis von mindestens einem flüchtigen Kosten / Nutzen-Analyse.
In einer kleinen eingebetteten Umgebung werden Sie entweder direkt an einen Echtzeit-Kernel werden Verknüpfen oder direkt auf der Hardware laufen. So oder so, müssen Sie sicherstellen, dass Ihr Runtime-Startcode behandelt C ++ spezifische Start Aufgaben richtig. Dies könnte so einfach sein wie dafür, dass die richtigen Linker-Optionen verwenden, aber da es üblich ist, die direkte Kontrolle über die Quelle an die Power On Reset Einstiegspunkt zu haben, müssen Sie möglicherweise die Prüfung, um sicherzustellen, dass sie alles tut. Zum Beispiel auf einer Coldfire-Plattform arbeitete ich an, die Entwickler-Tools mit einem CRT0.S Modul ausgeliefert, die die C ++ initializers vorhanden waren, aber auf Kommentar. Wenn es es direkt aus der Box verwendet hätte, wäre ich durch die globalen Objekte, deren Erbauer mystifiziert worden war überhaupt nicht ausgeführt werden.
Auch in einer eingebetteten Umgebung, ist es oft notwendig, Hardware-Geräte zu initialisieren, bevor sie verwendet werden kann, und wenn es keine OS ist und kein Bootloader, dann ist es Ihr Code, der das tut. Sie müssen sich daran erinnern, dass Konstrukteure für globale Objekte laufen vor main() genannt wird, so dass Sie Ihren lokalen CRT0.S (oder dessen Äquivalent) müssen modifizieren, dass Hardware-Initialisierung getan vor main() ist viel zu spät.
Nein. Jede der Sprache C ++ Funktionen, die vermieden werden kann Probleme (Runtime-Polymorphismus, RTTI, etc.) dazu führen könnten, während der Embedded-Entwicklung zu tun. Es ist eine Gemeinschaft von Embedded C ++ Entwickler (Ich erinnere mich, Spalten von Embedded-Entwickler mit C ++ in der alten C / C ++ Users' Journal zu lesen), und ich kann nicht vorstellen, dass sie sehr vernehmbar sein würde, wenn die Wahl so schlecht war.
Die Technischer Bericht über C ++ Leistung ist ein große Führer für diese Art der Sache. Beachten Sie, dass es einen Abschnitt über die Embedded-Programmierung betrifft hat!
Auch ++ auf die Erwähnung von Embedded C ++ in den Antworten. Der Standard ist nicht 100% meinen Geschmack, aber es ist ein gutes Stück Referenz bei der Entscheidung, welche Teile von C ++ Sie könnten fallen.
Während der Programmierung für kleine Plattformen, deaktivieren wir Ausnahmen und RTTI, vermieden virtuelle Vererbung und achteten auf die Anzahl der virtuellen Funktionen, die wir um liegen haben.
Ihr Freund ist der Linker Karte, aber:. Überprüfen sie häufig, und Sie werden schnell Quellen Code und statischer Speicher aufblasen beschmutzen
Danach wird die Standard-dynamische Speichernutzung zu berücksichtigen: in einer Umgebung wie ein eingeschränkt Sie erwähnen, können Sie nicht wollen dynamische Zuweisungen verwenden, überhaupt nicht. Manchmal kann man mit Speicherpools für kleine dynamische Allocs weg, oder „Frame-basierte“ Zuweisung wo Sie einen Block preallocate und später das Ganze werfen.
Ich empfehle den C ++ Compiler, aber Ihre Verwendung von C ++ Besonderheiten zu begrenzen. Sie können wie C in C ++ programmieren (der C-Laufzeit enthalten ist, wenn C ++ zu tun, obwohl in den meisten Embedded-Anwendungen, die Sie nicht nutzen die Standard-Bibliothek machen sowieso).
Sie können gehen Sie voran und verwenden C ++ Klassen usw., nur
- Beschränken Sie Ihre Verwendung von virtuellen Funktionen (wie Sie gesagt haben)
- Beschränken Sie Ihre Verwendung von Vorlagen
- Für eine Embedded-Plattform, möchten Sie den Betreiber neue und / oder Platzierung neu für Speicherzuweisung verwenden außer Kraft zu setzen.
Als Firmware / Systemingenieur eingebettet, kann ich euch etwas von dem Grund sagen, warum C immer noch die Nummer 1 über C ++ und ja, ich bin fließend in beiden.
1) Einige Ziele, die wir entwickeln auf hat 64kB RAM sowohl für Code und Daten, so dass Sie sich sicher, dass jedes Byte-Zählung zu machen, und ja, ich habe mit Code-Optimierung beschäftigt 4 Bytes zu speichern, die mich 2 Stunden kosten, und das ist im Jahr 2008.
2) Jede C-Library-Funktion überprüft wird, bevor wir sie in dem letzten Code lassen, wegen der Größenbeschränkung, so dass wir die Menschen lieber nicht teilen (keine Hardware-Teiler zu verwenden, so dass eine große Bibliothek ist erforderlich), malloc (weil wir kein Haufen haben, wird der gesamte Speicher von Datenpuffer in 512-Byte-Chunk zugeordnet und müssen Code überprüft) oder andere objektorientierte Praxis sein, die große Strafe tragen. Denken Sie daran, jede Bibliothek Funktion, die Sie Zahl verwenden.
3) Schon mal was von dem Begriff Overlay gehört? Sie haben so wenig Code-Raum, dass manchmal muss man die Dinge mit einem anderen Satz von Code auslagern. Wenn Sie eine Bibliothek-Funktion aufrufen, dann muss die Bibliotheksfunktion ansässig sein. Wenn Sie es nur in einer Overlay-Funktion verwenden, sind Sie verschwenden viel Platz auf zu viele objektorientierte Methoden verlassen. So übernimmt keine C-Library-Funktion, geschweige denn C ++ in Kauf genommen werden.
4) Gießen und sogar Verpackung (wo nicht ausgerichtete Datenstruktur Wortgrenze kreuzt) nötig ist, um aufgrund des begrenzten Hardware-Designs (das heißt einen ECC-Engine, die auf eine bestimmte Weise verdrahtet ist) oder mit einem Hardware-Fehlern zu bewältigen. Sie können nicht zu viel inplicitly annehmen, also warum Objekt orientieren es zu viel?
5) Worst-Case-Szenario: Ein Teil der objektorientierten Methoden eliminiert werden zu denken zwingen entwickeln, bevor sie Ressourcen verwenden, die (dh die Zuweisung 512bytes auf einem Stapel explodieren können, anstatt von einem Datenpuffer), und einige der potenziellen Schlimmste verhindern Case-Szenario, das für nicht getestet werden oder den gesamten Codepfad beseitigt alle zusammen.
6) Wir haben eine Menge Abstraktion verwenden Hardware von der Software zu halten und den Code so portabel wie möglich zu machen, und Simulation freundlich. Zugriff auf die Hardware muss in einem Makro oder Inline-Funktion eingewickelt werden, die zwischen den verschiedenen Plattform bedingt kompiliert werden, müssen Datentyp wie Byte-Größe gegossen werden, anstatt zielen auf spezielle, direkte Zeiger Nutzung ist nicht erlaubt (weil einige Plattform-Speicher übernehmen Mapped I / O das ist gleiche wie Datenspeicher), etc.
Ich kann von mehr denken, aber Sie bekommen die Idee. Us Firmware Jungs haben objektorientierte Ausbildung haben, aber die Aufgabe von Embedded Systems Hardware sein, so orientiert und niedriges Niveau, dass es nicht hohe oder abstrahierbar von Natur aus ist.
BTW, jeder Firmware-Job, den ich bei verwendet Steuerquelle war, ich weiß nicht, wo Sie diese Idee von erhalten.
-einige Firmware Typ von SanDisk.
Meine persönliche Präferenz ist C, weil:
- Ich weiß, was jede Zeile Code tut (und Kosten)
- Ich weiß nicht, C ++ gut genug, um zu wissen, was jede Zeile Code tut (und Kosten)
Warum sagen die Leute das? Sie nicht wissen, was jede Zeile von C tut, wenn Sie die asm Ausgabe überprüfen. Das Gleiche gilt für C ++.
Zum Beispiel, was asm erledigt diese unschuldige Erklärung produzieren:
a[i] = b[j] * c[k];
Es sieht ziemlich unschuldig, aber ein gcc basierten Compiler erzeugt diese asm für ein 8-Bit-Mikro
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
Die Anzahl der Anweisungen erzeugt wird, hängt massiv auf:
- Die Größen a, b und c.
- , ob werden diese Zeiger auf dem Stack gespeichert oder sind global
- , ob i, j und k auf dem Stack oder global sind
Dies gilt vor allem in den kleinen embedded world, wo Prozessoren C. einfach nicht eingerichtet zu handhaben So wäre meine Antwort, dass C und C ++ sind genauso schlecht wie jeder andere, wenn Sie die asm Ausgang immer prüfen, wobei sie genauso gut wie jeder andere.
Hugo
Ich habe gehört, dass einige Leute für eingebettete Arbeit C bevorzugen aufgrund der Tatsache, dass einfacher und daher leichter zu den eigentlichen Code vorhersagen, die generiert werden.
Ich persönlich würde denken, C-Stil C ++ zu schreiben (Vorlagen für Typsicherheit verwenden) Ihnen aber eine Menge Vorteile geben würde, und ich kann keinen wirklichen Grund, nicht sehen.
Ich sehe keinen Grund C zu verwenden anstelle von C ++. Was auch immer Sie in C tun können, können Sie es tun, auch in C ++. Wenn Sie möchten, Gemeinkosten von VMT zu vermeiden, verwenden Sie keine virtuellen Methoden und Polymorphismus.
Allerdings C ++ kann einige sehr nützliche Idiome ohne Overhead bieten. Einer meiner Favoriten ist RAII. Die Klassen sind nicht notwendig, teuer in Bezug auf Speicher oder Leistung ...
Ich habe einige Codes für ARM7 eingebettet paltform auf IAR Workbench geschrieben. Ich empfehle auf Vorlagen unter Berufung zu tun Compiler-Optimierung und Kursprädiktion. Vermeiden Sie dynamische Gießen wie die Pest. Verwenden Züge / Politik zu Ihrem Vorteil, wie in Andrei Alexandrescu Buch vorgeschrieben, Modern C ++ design .
Ich weiß, kann es schwierig sein, zu lernen, aber ich bin auch sicher, dass Ihr Produkt von diesem Ansatz profitieren.
Ein guter Grund, und manchmal der einzige Grund ist, dass es immer noch keine C ++ Compiler für das spezifische Embedded-System ist. Dies ist beispielsweise der Fall für Microchip PIC Mikrocontrollern. Sie sind sehr einfach zu schreiben für und sie haben einen freien C-Compiler (eigentlich eine leichte Variante C), aber es ist keine C ++ Compiler in Sicht.
Für ein System zu 4K RAM beschränkt, würde ich C, C ++ nicht, einfach so, dass Sie sicher sein können, alles zu sehen, dass es geht. Die Sache mit C ++, ist, dass es sehr einfach ist, weit mehr Ressourcen (CPU und Speicher) zu verwenden, als es wie Blick auf den Code aussieht. (Oh, ich werde nur ein weiteres BlerfObject schaffen, das zu tun ... hoppla! Aus dem Speicher!)
Sie können es in C tun ++, wie bereits erwähnt (kein RTTI, keine vtables, etc, etc), aber Sie werden so viel Zeit dafür, dass Ihre C verbringen ++ Nutzung von Ihnen nicht weg, wie Sie das tun würde Äquivalent in C.
Der menschliche Geist beschäftigt sich mit der Komplexität von so viel wie möglich zu bewerten und dann entscheiden, was wichtig ist, sich darauf zu konzentrieren, und Verwerfen oder den Rest Abwertung. Dies ist die gesamte Untermauerung hinter Marketing Branding und weitgehend, Symbole.
Diese Tendenz zu bekämpfen Ich ziehe C zu C ++, weil es zwingt Sie über Ihren Code zu denken, und wie es mit der Hardware ist die Interaktion enger - unerbittlich schließen.
Von langjährigen Erfahrung ist es meine Überzeugung, dass C zwingt Sie mit besseren Lösungen zu Problemen zu kommen, teilweise durch aus dem Weg bekommen und nicht zwingen Sie viel Zeit zu verschwenden eine Einschränkung einige Compiler-Schriftsteller Gedanken erfüllt war eine gute Idee, oder herauszufinden, was auf „unter der Decke“ geht.
In diesem Sinne, niedrige Sprachen wie C haben Sie verbringen viel Zeit auf die Hardware konzentriert und den Aufbau guter Datenstruktur / Algorithmus Bündel, während Hochsprachen haben Sie viel Zeit am Kopf kratzen verbringen fragen, was los ist auf da drin, und warum Sie etwas durchaus sinnvoll in Ihrem spezifischen Kontext und das Umfeld nicht tun können. Beating Compilers in der Unterwerfung (starke Typisierung ist der schlimmste Täter) nicht eine produktive Nutzung der Zeit.
ich passe wahrscheinlich die Programmierer Form gut - ich die Kontrolle mag. Aus meiner Sicht ist das kein Persönlichkeits Fehler für einen Programmierer. Kontrolle ist, was wir zu tun bezahlt. Genauer gesagt einwandfrei steuern. C gibt Ihnen viel mehr Kontrolle als C ++.
persönlich mit 4 KB Speicher würde ich sagen, Sie sind nicht immer so viel mehr Kilometer von C ++, so dass nur die eine auswählen, die die besten Compiler / runtime Kombination für den Job scheint, ist da die Sprache wahrscheinlich nicht viel los Materie .
Beachten Sie, dass es auch ohnehin nicht alles über die Sprache ist, da auch die Bibliotheksangelegenheiten. Oft haben C Libs eine etwas kleinere minimale Größe, aber ich könnte mir vorstellen, dass ein C ++ lib bei Embedded-Entwicklung ausgerichtet ist abgeholzt, so sicher sein, zu testen.
Einige sagen, dass C-Compiler kann viele effizienten Code generieren, weil sie müssen, um die erweiterten C ++ Funktionen nicht zu unterstützen, und können daher aggressiver in ihren Optimierungen.
Natürlich, in diesem Fall können Sie die beiden spezifischen Compiler auf die Probe stellen wollen.
C gewinnt auf Portabilität -, weil es weniger zweideutig in Sprache spec ist; deshalb viel bessere Portabilität und Flexibilität für verschiedene Compiler bieten etc (weniger Kopfschmerzen).
Wenn Sie nicht gehen, um C ++ Funktionen nutzen, um eine Notwendigkeit, dann mit C gehen zu treffen
Sehen Sie irgendeinen Grund mit C89 zu bleiben, wenn für sehr begrenzte Entwicklung Hardware (4 KB RAM)?
Persönlich, wenn es um Embedded-Anwendungen kommt (wenn ich eingebettet sagen, ich meine nicht zusammenzuzucken, iPhone, etc .. aufgebläht Embedded-Geräte heute). Ich meine begrenzte Geräte Ressourcen.
Ich ziehe C, obwohl ich mit C ++ ziemlich viel auch gearbeitet haben.
Zum Beispiel kann das Gerät, das Sie redest hat 4 kb RAM, auch nur aus diesem Grunde würde ich nicht C ++ betrachten. Sicher, können Sie in der Lage sein, etwas kleiner zu gestalten, C ++ und Ihre Nutzung den es in Ihrer Anwendung zu begrenzen wie andere Beiträge vorgeschlagen haben, aber C ++ „könnte“ potenziell verkompliziert am Ende / Blähungen Ihre Anwendung unter der Decke.
Wollen Sie statisch verknüpfen? Sie können statische eine Dummy-Anwendung mit c ++ vs c vergleichen möchten. Das kann dazu führen Sie C statt zu betrachten. Auf der anderen Seite, wenn Sie in der Lage, eine C ++ Anwendung in Ihren Speicheranforderungen zu bauen, geht für sie.
IMHO, In der Regel in Embedded-Anwendungen wie ich, alles wissen, was los ist. Wer verwendet Speicher / System-Ressourcen, wie viel und warum? Wann befreien sie ihnen?
Wenn für ein Ziel mit X Menge an Ressourcen zu entwickeln, CPU, Speicher, etc .. Ich versuche, auf der unteren Seite der Verwendung dieser Ressourcen zu bleiben, weil Sie nie wissen, welche künftigen Anforderungen kommen zusammen damit Sie mehr Code hinzufügen zu müssen das Projekt, die „vermeintliche“ wurde eine einfache kleine Anwendung sein, aber endet viel größer werden.
ist meine Wahl in der Regel von der C-Bibliothek bestimmt wir verwenden möchten, die ausgewählt wird, auf das, was das Gerät tun muss. Also, 9/10 mal .. es endet als uclibc oder newlib und C. Der Kernel verwenden wir ein großer Einfluss auf das ist auch, oder, wenn wir unsere eigenen Kernel gerade schreiben.
Es ist auch eine Auswahl an Gemeinsamkeiten. Die meisten guten C-Programmierer haben kein Problem mit C ++ (auch wenn viele die ganze Zeit beschweren sich, dass sie es verwenden) .. aber ich habe nicht das Gegenteil wahr zu sein (nach meiner Erfahrung).
gefundenAuf einem Projekt arbeiten wir (das beinhaltet einen Grund auf Kernel), sind die meisten Dinge in C getan, aber ein kleinen Netzwerk-Stack wurde in C ++ implementiert, da war es nur einfacher und unproblematischer zu implementieren C Vernetzung mit ++ .
Das Endergebnis ist, wird das Gerät entweder Arbeit und Abnahmetests bestehen oder wird es nicht. Wenn Sie foo in xx-Stack und Heap yy Einschränkungen mit Sprache z implementieren können, gehen für sie, verwenden, was Sie produktiver macht.
Meine persönliche Präferenz ist C, weil:
- Ich weiß, was jede Zeile Code tut (und Kosten)
- Ich weiß nicht, C ++ gut genug, um zu wissen, was jede Zeile Code tut (und Kosten)
Ja, ich bin zufrieden mit C ++, aber ich weiß es nicht so gut wie ich Standard-C tun.
Wenn Sie nun das Gegenteil von dem, sagen kann, na ja, verwenden, was Sie wissen :) Wenn es funktioniert, geht die Tests, etc .. Was ist das Problem?
Wie viel ROM / FLASH haben Sie?
4 kB RAM kann immer noch bedeuten, gibt es Hunderte von Kilobyte FLASH den eigentlichen Code und statische Daten zu speichern. neigt RAM auf dieser Größe nur für Variablen gemeint zu sein, und wenn man mit denen vorsichtig ist, können Sie ganz ein großes Programm in Form von Code-Zeilen in dem Speicher passen.
Allerdings neigt C ++ setzen Code und Daten in FLASH schwieriger zu machen, aufgrund der Laufzeitkonstruktionsregeln für Objekte. In C kann eine konstante struct leicht als Hardware-Konstante Objekt setzt in der Flash-Speicher und zugegriffen werden. In C ++ wäre ein konstantes Objekt den Compiler erfordern den Konstruktor zur Compile-Zeit zu bewerten, was ich denke, ist nach wie vor das hinaus, was ein C ++ Compiler tun kann (theoretisch, Sie könnte es tun, aber es ist sehr, sehr schwer in der Praxis zu tun) .
So in einem „kleinen RAM“, „großen FLASH“ Art von Umgebung würde ich jeden Tag mit C gehen. Beachten Sie, dass eine gute Zwischen Wahl i C99, die die meisten der schönen C hat ++ für verfügt über nicht-klassenbasierten-Code.
In der Regel nicht. C ++ ist ein Super-Satz von C. Dies vor allem für neue Projekte sein würde.
Sie sind auf dem richtigen Weg bei der Vermeidung von C ++ Konstrukte, die in Bezug auf die CPU-Zeit und Speicherplatzbedarf kann teuer werden.
Beachten Sie, dass einige Dinge, wie Polymorphismus sehr wertvoll sein kann - die wesentlichen Funktionszeiger sind. Wenn Sie Sie sie finden müssen, sie verwenden -. Weise
Auch gut (gut gestaltet) Ausnahmebehandlung können Sie Ihre Embedded-App zuverlässiger als eine App machen, die Dinge mit traditionellen Fehlercodes behandelt.
Der einzige Grund, C IMHO zu bevorzugen wäre, wenn die C ++ Compiler für Ihre Plattform nicht in einer guten Form ist (Buggy, schlechte Optimierung, etc.).
Das Buch C ++ für Spieleprogrammierer Informationen haben im Zusammenhang mit, wenn Codegröße wird basierend auf Features von C ++ erhöht.
Sie haben inline in C99. Vielleicht gefällt Ihnen ctors, aber das Geschäft des Erhaltens dtors kann richtig chaotisch. Wenn der verbleibende einzige Grund, nicht C Namespaces ist, würde ich wirklich zu C89 bleiben. Dies ist, weil Sie es auf eine etwas andere Embedded-Plattform zu portieren wollen könnten. Sie können später beginnen in C ++ auf dem gleichen Code zu schreiben. Aber Vorsicht die folgenden, in der C ++ ist kein Obermenge von C. Ich weiß, Sie sagten, Sie einen C89-Compiler, aber tut dies C ++ Vergleich mit C99 wie auch immer, als das erste Element zum Beispiel für jede C da K & R wahr ist.
sizeof 'a' > 1 in C, nicht in C ++. In C haben Sie variabler Länge Arrays VLA. Beispiel: func (int i) {int a [i] . In C haben Sie variable Array Mitglieder VAM. Beispiel:. struct {int b; int m [];}
Ich will nur sagen, dass es kein System mit „unbegrenzt“ Ressourcen. Alles in dieser Welt ist begrenzt und jede Anwendung sollte die Ressourcennutzung ganz gleich, ob seine ASM, C, Java oder JavaScript betrachten. Die Attrappen, die ein paar Mbs „nur um sicher zu sein“ macht iPhone 7, Pixel und andere Geräte extrem Luggy zuordnen. Egal, ob Sie 4kb oder 40 Gb haben.
Aber von einer anderen Seite Ressourcenverschwendung zu bekämpfen - ist eine Zeit, die diese Ressourcen sparen dauert. Wenn es 1 Woche Extra nimmt eine einfache Sache in C zu schreiben, ein paar Zecken und ein paar Bytes zu speichern, anstatt C ++ verwendet bereits implementiert, getestet und verteilt. Warum die Mühe? Es ist wie ein USB-Hub kaufen. Ja, Sie können es selbst machen, aber wird es besser sein würde? zuverlässiger? billiger, wenn Sie zählen Ihre Zeit?
Nur eine Seite Gedanken - auch Strom aus Steckdose ist nicht unbegrenzt. Versuchen Sie, zu erforschen, wo seine kommen und Sie werden sehen, vor allem seine aus der Verbrennung von etwas. Das Gesetz von Energie und Material ist immer noch gültig. Kein Material oder Energie erscheint oder verschwindet, sondern verwandelt
Für Speicherzuweisung Problem, kann ich mit Quantum-Plattform und seine Zustandsmaschine Ansatz empfehlen, da es alles ordnet man bei der Initialisierung Zeit bräuchten. Es hilft auch Konkurrenzprobleme zu lindern.
Dieses Produkt läuft sowohl auf C und C ++.
Es hängt von den Compiler.
Nicht alle Embedded-Compiler implementieren alle C ++, und selbst wenn sie es tun, könnten sie nicht auf die Vermeidung Code aufblasen gut sein (das ist immer ein Risiko mit Vorlagen ist). Testen Sie es mit ein paar kleineren Programmen finden Sie, wenn Sie auf Probleme stoßen.
Aber da ein gut Compiler, nein, es gibt keinen Grund, nicht C ++ zu verwenden.
Ich habe gerade ein Beispiel, wie ISO C ++ für Embedded-Entwicklung, das könnte interessant für jemanden, der die Entscheidung trifft, wenn die Verwendung C ++ oder C.
Es wurde von Bjarne Stroustrup bereitgestellt auf seiner Homepage :
Für einen Blick auf, wie ISO C ++ kann für ernsthafte Embedded-Systeme Programmierung verwendet werden, die JSF Luftfahrzeug C ++ Coding Standards .
Verschiedene Antwort Post auf einen anderen Aspekt der Frage:
"malloc"
Einige früheren Antworten sprechen ziemlich viel darüber. Warum denken Sie auch, dass Anruf existiert? Für eine wirklich kleine Plattform, neigt malloc nicht verfügbar ist, oder auf jeden Fall optional zu sein. dynamische Speicherzuweisung Der Implementierung neigt sinnvoll zu sein, wenn Sie einen RTOS haben, in der Unterseite Ihres Systems - aber bis dahin ist es rein gefährlich.
Sie können ohne sie sehr weit kommen. Man denke nur an all die alten Fortran-Programme, die nicht einmal einen richtigen Stapel für lokale Variablen hatte ...
Es gibt eine Reihe von verschiedenen Controller-Hersteller rund um den Globus und wenn Sie einen Blick in ihre Entwürfe und die Befehlssätze nehmen, die verwendet werden müssen, um zu konfigurieren, dass Sie in einer Menge Probleme können am Ende. Der Hauptnachteil ist, dass die Assemblersprache Maschinen / Architektur abhängig. Es ist wirklich riesig für einen Entwickler bitten, von Herzen alle da draußen setzen Anweisungen Codierung für verschiedene Steuerungen zu erreichen. Deshalb C in Embedded-Entwicklung immer beliebter geworden, weil C auf hohem Niveau genug zu abstrahieren die Algorithmen und Datenstrukturen von hardwareabhängigen Details ist, so dass der Quellcode tragbare über eine Vielzahl von Ziel-Hardware, Architektur unabhängige Sprache und sehr leicht zu konvertieren und den Code zu halten. Aber wir sehen einige High-Level-Sprachen (objektorientiert) wie C, C ++, Python, Java usw. entwickeln sich genug, um sie unter dem Radar der Embedded-System-Entwicklung zu machen.
Auf einer solchen begrenzten System. Gehen Sie einfach für Assembler. Gibt Ihnen die totale Kontrolle über jeden Aspekt, und gibt keinen Overhead.
Wahrscheinlich zu viel schneller, da viele Embedded-Compiler sind nicht die besten Optimierer (vor allem, wenn man es auf dem Stand der Technik Compiler wie die, vergleicht wir für den Desktop (intel haben, Visual Studio, etc.))
"yeah yeah ... aber c ist wiederverwendbar und ...". Auf einer solchen begrenzten System, die Chancen sind Sie nicht viel von diesem Code auf einem anderen System sowieso wiederverwenden. Auf dem gleichen System, Assembler ist nur als wiederverwendbare.
