"mich wenig mit Pointern und "manueller" Speicher-Allokation beschäftigt habe. "
ein paar letzte Hinweise:
1. alles was du manuell dynamisch anlegst, musst du auch manuell wieder freigeben...
2. alles was der C++ Compiler statisch für dich anlegt, kannst und darfst du nicht manuell freigeben
3. den Unterschied zwischen statisch/automatisch vom Compiler erzeugten Objekten siehst du sehr gut um C/C++ Code... denn einmal schribst du o.??? und dynamisch o->??? also z.B. Valve.SwitchOn() bzw. Valve->SwichOn()
4. Wenn du lieber ohne NEW mit automatisch erzeugen Objekten arbeitest, lege deine "temporär" benötigten Objekte NICHT in der Klasse an, sondern erzeuge sie als Lokalvariablen in den Methoden, wo sie temporär lokal gebraucht werden... damit nutzt du die "ScopeBasierte" und vom C/C++ Compiler garantierte Speicherverwaltung bestmöglich und musst nicht bei jedem "return" irgendwo in einer Methode dran denken, welche Sachen an dieser Stelle vorher dynamisch manuell von dir erzeugt wurden und jeweils vor jedem "return" von dir auch passend wieder freigegeben werden müssen
5. auch wenn sich hier der Mehrheit wohl die Fußnägel kräuseln... unter 32Bit Embedded ist es keine Schande statt zig "return(1)" oder "return(0)" besser zig lokale "goto RetOK" bzw. "goto RetERR" zu schreiben, und jeweils via zwei lokaler "Sprungziele" am Ende jeder Funktion dort zentral manuell alles dynamische aufzuräumen. Ja, das is OldScool C-Style, aber try exept und das absichtliche "werfen mit Exeptions" erzeugen auf EmbeddetCPUs irwitzigen
ASM Code und die Stackgröße kann explodieren, wenn real ein Fehler an einer Stelle kommt, wo der HW begrenzte Stack für den normal Ablauf gerade noch gereicht hat
So ich programmiere heute noch 8Bit alles 256Byte-SRAM/4KbFlashROM über 1KB/32KB bis 4KB/64KB und weils funktioniert auch USB und TFT-Display taugliche 16BITer mit 32KB-
RAM/256KB-FlashROM... halt mit eigener Hardware und nix Adruino, und weil ich zufällig auch echtes OO-C++ und Delphi kann, stehe ich absolut bewußt dazu für bestimmtes eben der Effektivität wegen auf kompkaten OldScool Style zu setzen... den ich auf Grund meines Alters halt zum Glück auch (noch) sehr gut kenne und selbst auch im Schlaf kann.
Adruino&Co finde ich gut, denn so wird heute einer neuen Generation von Embedded Programmieren der Einstieg in die HW abhängige Entwicklung&Programmierung wesentlich erleichtert.
Wenn es nicht um UltraLowPower oder die Einsparung von wenigen USD in Großserie geht, soll heut doch alles in C++ mit 16/32BITer gemacht werden. ab 64+KB-
RAM und 512+KB-Programmspeicher ist USB, Grafik, Ethernet oder jegliche sonstige Kommunikation und IO-Steuerung heute fast völlig problemlos in C++ zu programmieren
