Allerdings hab ich mir jetzt auch die verketteten Listen angesehen..
Aber rein von der Logik her würde ich schon gerne eine Gruppe bzw. Kollektion der Elemente einer Gruppe direkt griffbereit haben, so war jedenfalls die Idee mit dem Struct einer Gruppe von Elementen. Ich will aber nicht ausschließen das es nicht mit verketten Listen auch geht, ist halt nur etwas unpraktikabel
Guter Vergleich zwischen Array und verketteter Liste:
Kurzfazit daraus: Entgegen der ersten Intuition ist beim Einfügen/Entfernen mitten in der Datenstruktur das Array (oft massiv) schneller als die Liste, obwohl beim einen alle nachfolgenden Elemente komplett kopiert und beim anderen nur ein paar wenige Zeiger verbogen werden müssen. Das liegt am unglaublichen Schneckentempo des RAM im Vergleich zur CPU, weshalb man möglichst viele Datenzugriffe auf die schnelleren Caches anstatt den Hauptspeicher haben will. Je enger gepackter die Datenstruktur, desto höher ist die Wahrscheinlichkeit eines (schnellen) Cache Hit.
Davon abgesehen stell dir auch mal die Frage, wer in deinem Programm auf wen wartet: Der Benutzer auf den Computer oder umgekehrt? Wenn der Mensch im Sekundentakt klickt und die Rechenzeit für die ausgelösten Aktionen im 100-ms-Bereich liegt, dann ist eine Optimierung auf 50ms aus menschlicher Sicht für die Katz. Zumindest für die reine Geschwindigkeit. Gerade in mobil, wo Batterielaufzeit wichtig ist, wird das schon wieder komplexer.
Solange du mit Gruppen von ein paar Dutzend Elementen arbeitest, wirst du kaum einen Unterschied feststellen können. Der Link von oben verlinkt eine PDF mit Beispieldaten. Dort geht die Skala bei 100000 Elementen los und Array und Liste sind an der Stelle noch grob gleichauf.
Da du GCC verwendest, ist als Performance-Profiler sicher gprof einen Blick wert, weil der dabei ist. Bin dafür aber nicht wirklich ein Experte.
Ein Objekt, das ich mit new anlege geht aber erst mit Beendigung des Programms "out-of-scope", ansonsten musst Du es mit delete zerstören (analog zu *alloc/free)
Trotzdem musst du im Destruktor immer noch manuell deine Speicherbereiche freigeben.
Ich habe das Gefühl, ihr denkt zu sehr in C-Logik. Warum würde ich ein Objekt manuell mit new erzeugen wollen? C++ lebt von
, das wiederum darauf aufbaut, dass Stack-Objekte out-of-scope gehen und dabei automatisch Destruktoren aufgerufen werden. Konsequent angewendet führt das in modernem C++ dazu, dass man praktisch nie mehr manuell new’t und delete’t und selten Destruktoren schreibt. Wenn ich persönlich in die Lage komme, einen Destruktor schreiben zu müssen, weil ich Ressourcen wegräumen muss, dann geht die rote Warnflagge hoch. Das ist ein Hinweis auf ein potenzielles Design- oder Implementierungsproblem. Der compilergenerierte Default-Destruktor plus das Ressourcenmanagement, das mir die Standard Library abnimmt, ist in der überwältigenden Anzahl aller Fälle vollkommen ausreichend.
Für die Fälle, wo ich wirklich mal ressourcenverwaltende Pointer braucht, gibt es unique_ptr und shared_ptr als Wrapper. Darüber kann man auch recht gut malloc/free-lastigen C-Code anbinden.
Man muss sich nur auf die Fähigkeiten von C++ einlassen, dann kann Ressourcenmanagement (übrigens nicht nur Speicher, sondern auch Handles, Sockets, DB-Verbindungen usw.) tatsächlich vollautomatisch vonstatten gehen.
).
) Gibt es doch jede menge Hochsprachen die einem die Speicherverwaltung vollständig abnehmen und für vieles recht optimierte Funktionen zur Verfügung stellen über die sich dann div. Professoren und Wissenschaftler vielleicht schon bessere Gedanken gemacht haben als man es persönlich je könnte (Klar nicht durchgängig und jeder Mensch macht Fehler ^^).