C und C++
-
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
-
http://www.mikrocontroller.net/wiki/C_vs_C-Plusplus schrieb:
Die tatsächlichen Implementierungen von C++ bemühen sich weniger als die von C, ausführbare Programme (Executables) in der sparsamsten möglichen Form zu erzeugen.
Yeah...you made my day
gruss
v R
