Embedded Programmierung mit C++ / Stdlibc++
-
Artchi schrieb:
Egal was die Menschen täglich machen bzw. benutzen, kann ein materieller oder menschlicher Schaden entstehen. Irgendwo in einer Kette, ist höchstwahrscheinlich ein Stück C- oder C++-Code mit im Spiel.
Allein daß es so ist, heißt nicht, daß es gut ist, wie es ist.
-
Angsthase schrieb:
Tim schrieb:
definition: schrieb:
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
Dann ist die Behauptung, dass dort C und/oder C++ nicht eingesetzt wird, falsch.
Ja, denn wie überall gibt es auch dort Wahnsinnige, die sich der Risiken nicht bewußt sind (Buffer Overflows, Wild Pointers, ...) und sie treiben einen irren Testaufwand.
So etwas wird halt nicht von Informatikern oder ähnlichem entwickelt. Das erhöht die Sicherheit natürlich ungemein!
-
Danke für Eure Beiträge!
Macht es eigentlich Sinn, oder kommt es häufiger in Praxis vor, C++ ohne die STL (und iostreams) einzusetzen? Ich habe mal ein wenig rumgespielt und wenn ich auf die STL verzichte, habe ich deutlich kompaktere Binaries.
-
Ohne konkretere Informationen zu deinem "embedded" Projekt kann man da wenig sinnvolle Tips geben. Dazu ist der Bereich "embedded" einfach viel zu groß.
-
Die Frage bezog sich jetzt nicht konkret auf eine Architektur oder auf den Embedded Bereich, sondern mehr auf den Zusammenhang zwischen STL (und iostreams) und der daraus resultierenden Programmgröße. Bei meinem Embedded Bereich handelt es sich primär um die Intel ixp4 Familie.
-
Es gibt mehrere alternative stl-Implementierungen, die wesentlich kleiner sind, z. B. uClibc++. Die habe ich unter FreeWRT verwendet. Sie ist vollständig genug, um mein Tntnet damit laufen zu lassen. Und Tntnet verwendet die STL und iostreams.
-
Du könntest die STL schlanker machen. Ich hab mal gelesen das das bei vielen komerziellen Projekten so gemacht wird.
-
Ich verwende für einen Experimental-Roboter namens Nibo sowohl C als auch C++-Programme. Letzteres geht ganz gut, wenn man ein paar Randbedingungen beachtet. Siehe: http://www.henkessoft.de/Roboter/Nibo.htm und http://www.roboternetz.de/phpBB2/viewtopic.php?t=31963&postdays=0&postorder=asc&start=66
Das geht, weil hier ein ATmega128 mit 4 KB SRAM - via I²C flankiert durch zwei ATtiny44 - eingesetzt wird.
http://nibo.editthis.info/wiki/Haupt-Controller
http://nibo.editthis.info/wiki/ATmega128
-
rüdiger schrieb:
Angsthase schrieb:
Ja, denn wie überall gibt es auch dort Wahnsinnige, die sich der Risiken nicht bewußt sind (Buffer Overflows, Wild Pointers, ...) und sie treiben einen irren Testaufwand.
So etwas wird halt nicht von Informatikern oder ähnlichem entwickelt. Das erhöht die Sicherheit natürlich ungemein!
Von wem denn sonst? Von Maurern oder Dachdeckern?
-
Badestrand schrieb:
rüdiger schrieb:
Angsthase schrieb:
Ja, denn wie überall gibt es auch dort Wahnsinnige, die sich der Risiken nicht bewußt sind (Buffer Overflows, Wild Pointers, ...) und sie treiben einen irren Testaufwand.
So etwas wird halt nicht von Informatikern oder ähnlichem entwickelt. Das erhöht die Sicherheit natürlich ungemein!
Von wem denn sonst? Von Maurern oder Dachdeckern?
nö, von solchen wie rüdi, wenn er mit der ausbildung fertig ist.
-
Dipl.-Ing. univ. schrieb:
nö, von solchen wie rüdi, wenn er mit der ausbildung fertig ist.
Was studiert der denn? Diplom-Ingenieur universalis
Ansonsten: Aha