Ich überlege STL in einem Embedded Projekt zu verwenden. Welche Gründe sprechen dafür, welche dagegen? Hat hier jemand Erfahrung? Danke+LG
Prinzipiell sind wohl alle Klassen aus der STL problematisch, welche dynamische Speicher reservieren. Bei dynamischer Speicherreservierung kann zu fragmentierung des Speichers führen, sodass dann zukünftige Allocations fehlschlagen obwohl insgesamt noch genug Speicher frei ist. Wobei du mal definieren solltest was du genau als embedded Bezeichnest. Ein kleiner ATtiny mit 512 Byte RAM oder Raspberry Pi mit 512MB RAM? Bei letzterem spricht nichts gegen dynamische Speicherverwaltung. Es gibt aber auch eine Reihe Klassen und Funktionen, welche ohne Speicherreservierungen auskommen. Ich habe z.B. schon den std::sort Algorithmus mit einem C-Array bei einem Projekt auf einem STM32F4 benutzt. Eine std::map<std::string, std::vector<float>> würde ich aber nicht gerade benutzten wollen.
Michael W. schrieb: > Ich überlege STL in einem Embedded Projekt zu verwenden. Welche > Gründe > sprechen dafür, welche dagegen? Hat hier jemand Erfahrung? > > Danke+LG Auf einem stm32 würde ich es nicht laufen lassen. Da sollte keine dynamische Speicherverwaltung sein. Wenn du aber sowieso eine linux Kiste hast, warum nicht? Was hast du denn für eine Hardware? Cup, Speicher, os? Gruß, adib.
Dagegen spricht, dass die STL eine alte Library ist, die vermutlich überhaupt nicht mit heutigen Compilern verwendet werden kann, dass du wenig Support im Internet finden wirst, dass wenige Libraries dazu kompatibel sind etc. Es ist stark zu empfehlen, stattdessen einfach die beim Compiler mitgelieferte Standard C++ Library zu verwenden. Die wurde quasi aus der STL entwickelt, ist standardisiert, überall verfügbar, kann mehr, beherrscht jeder C++ Programmierer. Die Verwendung der Standard C++ Library ist sehr sinnvoll, denn sie bietet viele nette Tools und Algorithmen, die einem das Leben einfacher machen, die man nicht selbst neuzuerfinden braucht.
M.W. ist bei der AVR-toolchain gar keine STL mit dabei, deshalb erübrigt sich hier die Frage. Aber embedded ist ja noch etwas mehr... Was eventuell dagegen sprechen könnte je nach Firmenumgebung ist, daß gelegentlich exceptions verteufelt werden - damit entfällt vieles aus der STL, solange bei jeder Allokierung ein new fehlschlagen könnte. Das kann man umgehen, ist aber ziemlich aufwendig. Ich halte aber exceptions für so wertvoll, daß ich sie lieber habe als eine selbstgestrickte Fehlerbehandlung, die dann im Notfall doch nicht funktioniert.
Dr. Sommer schrieb: > Dagegen spricht, dass die STL eine alte Library ist, die vermutlich > überhaupt nicht mit heutigen Compilern verwendet werden kann, dass du > wenig Support im Internet finden wirst, dass wenige Libraries dazu > kompatibel sind etc. Gemeinhin versteht unter STL aber immer noch den Teil der C++-Lib, die sie schon immer war.
Klaus Wachtler schrieb: > Gemeinhin versteht unter STL aber immer noch den Teil der C++-Lib, die > sie schon immer war. War sie nie. Die STL ist inkompatibel zur C++ Standard Library. Siehe hier: http://de.wikipedia.org/wiki/Standard_Template_Library#Bezug_zur_C.2B.2B-Standardbibliothek Klaus Wachtler schrieb: > Das kann man umgehen, ist aber ziemlich aufwendig. Geht, man muss nur die "nothrow" Variante von "new" verwenden, und dies per Allokator an allokierende Klassen weitergeben.
Ich habe kürzlich "Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming" von Chris Kormanyos für mich entdeckt. Da steht viel zum Thema, insbesondere C++11, Templates und zur C++ Standart Lib - am Beispiel eines AVR. Unter anderem auch unter dem Aspekt der Speicherverwaltung. Überladene New Operatoren und Speicherpools. Hat mich überzeugt auf uCs C++ einzusetzen.
Dr. Sommer schrieb: > Klaus Wachtler schrieb: >> Gemeinhin versteht unter STL aber immer noch den Teil der C++-Lib, die >> sie schon immer war. > War sie nie. Die STL ist inkompatibel zur C++ Standard Library. Siehe > hier: > http://de.wikipedia.org/wiki/Standard_Template_Lib... Ja, genug der Korinthenscheißerei. Ich gehe mal davon aus, daß der OP nicht die Original-STL nehmen will. > > Klaus Wachtler schrieb: >> Das kann man umgehen, ist aber ziemlich aufwendig. > Geht, man muss nur die "nothrow" Variante von "new" verwenden, und dies > per Allokator an allokierende Klassen weitergeben. ... und dann noch jede Stelle in den Containern dazu überreden, daß er bei einem new mit Rückgabe NULL sinnvoll reagiert :-)
Adib schrieb: > Was hast du denn für eine Hardware? Cup, Speicher, os? * Blackfin AD 533 * 32MB RAM * proprietäres OS Die Blackfin Toolchain hat eine "Abridged C++ Library", die gegenüber der Standard C++ Biboliothek stark abgespeckt ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.