Char - Array und Pointer

[HaWe]

ja, hmm, ok, evtl, aber die Frage wurde ja schon beantwortet:
aus C und C++ compilierte Executables können ihren eigenen Programmcode nicht während der Laufzeit ändern und daher können auch keine neuen Variablen während der Laufzeit hinzugefügt werden.

[Moppi]

Nochmal nachgeschoben:

Das was du möchstest erreichst du nur wenn du ein sich selbst modifizierendes Programm IN einer Programmierrsprache deiner Wahl schreibst.

Das ist das, was ich schon, im größeren Rahmen, getan habe. Nun stellte sich für mich die Frage, ob es auch für die kleinen µC, programmiert auf C-Basis, eine effektivere Möglichkeit gibt (weil die langsamer sind und weniger Speicherplatz zur Verfügung haben). Scheint aber so nicht zu sein, dafür gibt es z.B. verkette Listen. Nu muss ich sehen, ob ich Willens bin, daraus etwas zu machen.




MfG

- - - Aktualisiert - - -

ja, hmm, ok, evtl, aber die Frage wurde ja schon beantwortet

Ja, war sie meiner Meinung nach schon, wenn vielleicht auch an anderer Stelle.



MfG

- - - Aktualisiert - - -

Weil ich das ganz gut erklärt fand, hier mal ein Link:

https://www.virtual-maxim.de/dynamis...kettete-liste/

[HaWe]

Weil ich das ganz gut erklärt fand, hier mal ein Link:

https://www.virtual-maxim.de/dynamis...kettete-liste/

ja, danke für den Link, das ist gut erklärt!
Und es funktioniert genau wie schon oben geschrieben wurde, über dynamische Erzeugung neuer Variablenwerte
Listenelement *neuesListenelement = new Listenelement(film);
genau wie man sonst auch per new einen neuen Variablenwert dynamisch auf dem Heap erzeugt, aber eben ohne die Struktur selber zu verändern
Listenelement(Film film)
{
this->film.genre = film.genre;
this->film.jahr = film.jahr;
this->film.titel = film.titel;
this->nachfolger = NULL;
}

[Ceos]

der Vorteil einer verketteten Liste ist weniger Speicherverwürfelung, erzeuge ich eine Liste mit 10 Elementen und ist diese dynamisch aber im Speicher als Array konzipiert, ist der Zugriff auf einzelne Elemente schneller als bei eienr verketteten Liste. Eine Änderung der größe bedingt dann allerdings dass man genug Platz übrig haben muss und ggf. die ganze Liste irgendwo neu hinkopieren muss.

Eine verkettete Liste muss nur das Speicher-Objekt erzeugen und die Kettenglieder verlinken, daher habe ich das extra erwähnt, allerdings auf kosten der Suchzeit nach Einzel-Elementen, da man erst die Elemente einzeln über die Kettenglieder ablaufen muss (gerade auf dem meist begrenztem RAM eines µC)

Rand Info: C# und Java brauchen kein "klassisches" Speicher Management bei dem man sich selbst um das löschen der Objekte kümmern muss, die lassen das Objekt einfach liegen und ein Mechanismus genannt Garbage Collector räumt hinterher auf, indem er zur Laufzeit (ich meiner hier die Zeit wenn die Applikation arbeitet und nicht pausiert ist) die Objekte im Speicher prüft ob noch Refereenzen darauf existieren und diese ggf. zum löschen markiert. In einem kurzen Zeitfenster, in dem die Applikation dann angehalten wird, löscht er die Objekte aus dem Speicher. (ACHTUNG: das war sehr vereinfacht und umfasst nichtmal 10% der tatsächlichen Speicheverwaltung oder Nebenwirkungen die damit einhergehen)

[HaWe]

Noch ein paar pros/cons dazu:
Wegen des begrentzen RAMs bei Arduinos ist die Anzahl der verketteten Listen-Einträge ebenfalls nur recht klein und wird nicht zu einem Geschwindigkeitsproblem führen.
Blättern vor/zurück lässt sich mit einer doppelt verketteten Liste erhöhen.
Zeitkritsch sind eher schon SD-Lade- und Speichervorgänge, aber auch das wird sich bei der zwangsläufigen Listenkürze in Grenzen halten.
Da man solche Listeneinträge sicher nicht jede Sekunde immer wieder neu erzeugt und andere löscht, wird es vermutich auch nicht massive Speicherfragmentierung oder gar Speichergarbage geben, und bei jedem Neustart wird ja auch immer wieder neu aufgeräumt, also ist man wohl mit new/delete auf der hinreichend sicheren Seite, während andererseits auto_ptr etc. wieder deutlich höheren Speicherbedarf hat.