C und C++
-
proggingmania schrieb:
rüdiger schrieb:
Das halte ich für ein Gerücht, vor allem da C nährungsweise eine Untermenge von C++ ist...
Bei Microcontrollern mit wenigen KByte RAM bleibt dir nichts anderes übrig als C zu benutzen.
Die Dinge, die C++ ausmachen( Templates, Vererbung, STL) kannst du da in die Tonne hauen.
Gerade Templates sorgen doch für kleinen Code. Es gibt Firmen in denen es Policy ist, das man jede Klasse als Template schreibt, weil der Compiler so kleineren Code erzeugt (so sagt es zumindest Stroustrup in HOPL-III und bezieht sich dort zumindest auf Lockheed Martin).
-
rüdiger schrieb:
Gerade Templates sorgen doch für kleinen Code.
Ja, in Verbindung mit mehreren Datentypen.
Bei den Microcontrollern da gibts nicht sowas wie
float, double, char*, string, vector, etc..
Da sind Hexadezimalwerte angesagt.rüdiger schrieb:
Es gibt Firmen in denen es Policy ist, das man jede Klasse als Template schreibt, weil der Compiler so kleineren Code erzeugt (so sagt es zumindest Stroustrup in HOPL-III und bezieht sich dort zumindest auf Lockheed Martin).
Ja, aber wohl kaum in der Microcontrollerbranche.
-
proggingmania schrieb:
rüdiger schrieb:
Gerade Templates sorgen doch für kleinen Code.
Ja, in Verbindung mit mehreren Datentypen.
Bei den Microcontrollern da gibts nicht sowas wie
float, double, char*, string, vector, etc..
Da sind Hexadezimalwerte angesagt.So ein Blödsinn.
rüdiger schrieb:
Es gibt Firmen in denen es Policy ist, das man jede Klasse als Template schreibt, weil der Compiler so kleineren Code erzeugt (so sagt es zumindest Stroustrup in HOPL-III und bezieht sich dort zumindest auf Lockheed Martin).
Ja, aber wohl kaum in der Microcontrollerbranche.
Natürlich reden wir hier über µC...
-
Najanun, Ausnahmen bestätigen die Regel, das weißt du auch
-
proggingmania schrieb:
Najanun, Ausnahmen bestätigen die Regel, das weißt du auch
Du meinen was? Ich nix verstehen.
-
Ich glauben dir gern das du das nicht tun.
Meine Ausführungen beziehen sich auf gängigen Industriestandard.
An einer Fachhochschule habe ich einem mehrmonatigen Seminar über hardwarenahe Systemprogrammierung meine oben genannten 'Weisheiten' gelernt und hier weitergegeben.Rüstung, Raumfahrt, Militäranwendungen waren da nicht mit inbegriffen
Das sehe ich durchaus als eine Ausnahme an.Edit:
-
Meine Ausführungen beziehen sich auf gängigen Industriestandard.
An einer Fachhochschule habe ich einem mehrmonatigen Seminar über hardwarenahe Systemprogrammierung meine oben genannten 'Weisheiten' gelernt und hier weitergegeben.Ah, eine Fachhochschule definiert jetzt Industriestandards? Interessant. Aber selbst wenn der(?) Industriestandard sagt, das Templates böse seien, so kannst du es doch ganze einfach nachmessen.
Du könntest aber zB auch im HOPL-III über C++ oder im ISO C++-Standard nachlesen, welche Vorteile Templates haben. Der Compiler darf nämlich ungenutzten Code entfernen und hat mehr Freiheiten beim Umgang mit Templates. Daher ist er in der Lage kleineren Code zu produzieren. Aber klar, dein Kurs an der Fachhochschule mit _dem_ Industriestandard, hat natürlich was anderes gesagt. Also vergrab lieber deinen Kopf im Sand und erzähl allen wie blöd Templates doch sind, weil die nichts mit Hexdezimalwerten zu tun haben...
-
Ich habe weder behauptet, das die FH Standards definiert, noch das der Industriestandard sagt das Templates böse seien. Das hast du dir mal eben so aus den Fingern gesogen.
Es ist durchaus denkbar, das die Möglichkeit der Benutzung von Templates mittels C++ an der speziellen FH nicht bekannt ist.
-
rüdiger schrieb:
Du könntest aber zB auch im HOPL-III über C++ oder im ISO C++-Standard nachlesen, welche Vorteile Templates haben. Der Compiler darf nämlich ungenutzten Code entfernen und hat mehr Freiheiten beim Umgang mit Templates.
Darf er bei Nicht-Template-Code ungenutzten Code nicht wegräumen?
-
Bashar schrieb:
rüdiger schrieb:
Du könntest aber zB auch im HOPL-III über C++ oder im ISO C++-Standard nachlesen, welche Vorteile Templates haben. Der Compiler darf nämlich ungenutzten Code entfernen und hat mehr Freiheiten beim Umgang mit Templates.
Darf er bei Nicht-Template-Code ungenutzten Code nicht wegräumen?
In Shared Libraries nur bedingt.
-
@Bashar
http://www.cs.tamu.edu/news/items?id=1797
Siehe Seite 31
-
Naja, in einer Library darf er sicherlich nichts wegschmeissen... wäre auch irgendwie ungünstig für den nächsten Lib-Nutzer.
Aber wenn die endgültige Exe erstellt wird, darf wohl ein Linker bzw. Optimierer ungenutzten Code rausschmeissen.Ich habe hier eine statische Library, die recht groß ist. Wenn ich davon nur sehr wenig nutze, ist meine Exe nicht so groß (nicht mal annähernd so groß) wie die Library.
Aber Templates haben Vorteile, der der Compiler sich z.B. das optimaler Funktionstemplate raussuchen kann. Sowas steht ja in "Modernes C++ Design" drin... müsste ich nochmal nachschauen.
-
-
ich kann dort nirgendwo lesen, dass man bei mikrocontrollern die "features die C++ ausmachen in die tonne treten kann".
-
Also bei BMW hat man bzgl. C++ und Embedded gute Erfahrungen gemacht:
http://www.elektroniknet.de/index.php?id=2148Gegen C++ im Embedded-Bereich werden oft Punkte angeführt wie: „C++ ist langsamer als C“, „C++ ist viel schwieriger zu verstehen als C“, „C++-Programme brauchen mehr Platz als C-Programme“ oder „Abstraktion bedeutet Ineffizienz“. Diese Aussagen müssen aber im passenden Kontext gesehen werden. Sie entstehen, weil die meisten Programmierer nicht wissen, wie die verwendeten Sprachmerkmale tatsächlich vom Compiler umgesetzt werden. Dieser Artikel zeigt, welche Konzepte von C++ für den Einsatz in der Embedded-Programmierung geeignet sind und die helfen können, zukunftsfähige Software-Systeme zu entwickeln.
-
dot schrieb:
ich kann dort nirgendwo lesen, dass man bei mikrocontrollern die "features die C++ ausmachen in die tonne treten kann".
fussangel-beispiele 1 und 2
Artchi schrieb:
Also bei BMW hat man bzgl. C++ und Embedded gute Erfahrungen gemacht...
...aber oft wird der grossteil solcher CAN-sachen schon von der hardware abgefrühstückt (frame buffers, message-id filter usw. sind aus performancegründen oft in der hardware integriert), d.h. man muss nicht alles nochmal in software nachbauen (so wie sie's da machen mit dieser CANFrame klasse wobei z.b. mit CANFrame::setPayload daten überflüssigerweise in ein C++ objekt mit 'memcpy' kopieren werden). das ist zwar alles schön objektorientiert, aber auch ein paradebeispiel für overhead, den man sich durch eine auf C++ zurechtgestutzte architektur einhandelt.
da haben die sich schon einen niedlichen 'CAN abstraction layer' gebastelt...
-
pale dog schrieb:
dot schrieb:
ich kann dort nirgendwo lesen, dass man bei mikrocontrollern die "features die C++ ausmachen in die tonne treten kann".
fussangel-beispiele 1 und 2
Fußangel-1 ist ein dämliches Beispiel. Mit schlechten Programmierrichtlinien kann man doch bitte nichts rechtfertigen.
Fußangel-2 finde ich ziemlich künstlich. Man baut ja kein std::cout << "hello world\n"; für µC...Außerdem haben die nichts mit "C++ Features" zu tun
-
rüdiger schrieb:
Fußangel-1 ist ein dämliches Beispiel. Mit schlechten Programmierrichtlinien kann man doch bitte nichts rechtfertigen.
mit schlechten programmierrichtlinien ist etwa sowas gemeint: http://www.cs.helsinki.fi/u/vihavain/s00/cpp/idioms.html
also dinge, die für C++ coder zum guten ton gehören, auf schwach bestückten systemen aber fatale folgen haben können.rüdiger schrieb:
Fußangel-2 finde ich ziemlich künstlich. Man baut ja kein std::cout << "hello world\n"; für µC...
da geht's um die vielen sachen, die C++ einem freundlicherweise unterjubelt, um das programmieren einfacher und sicherer zu machen.
...aber die gibt's leider nicht gratis
-
pale dog schrieb:
da haben die sich schon einen niedlichen 'CAN abstraction layer' gebastelt...
Ich frage mich was da passiert wenn die mal einen extended frame bekommen :p
Zudem fehlt mir in diesem Artikel immernoch das Argument pro C++. Dass man einen Mikrocontroller auch mit C++ programmieren kann war doch längst klar. Wo ist die Neuigkeit?
-
Tim schrieb:
pale dog schrieb:
da haben die sich schon einen niedlichen 'CAN abstraction layer' gebastelt...
Ich frage mich was da passiert wenn die mal einen extended frame bekommen :p
na, class ExtendedCANFrame : public CANFrame {...};
mit C++ hat man ja immer die möglichkeit, noch eins draufzusetzen
