Speicherreservierung Sinnvoll? C++

[KingwondA]

Ich gehe meinen Weg als Spieleprogrammierer (hobby) und in meinem Buch was ich lese wird erwähnt, dass es sinnvoll ist Instanzen, Variablen auf dem Heap anstatt auf dem Stack zu erzeugen/speichern.

Meine Frage nun: Bringt das Speichern auf dem Heap eine spürbare verbesserung?

Bis auf die Tatsache das ich die Größe eines Array nun zur Laufzeit angeben kann bringt mir dass speichern auf dem Heap doch nur ein paar taktzyklen an verbesserung.

[MrSm!th]

Wie meinst du "Speicher reservieren"?

[Actidnoide]

Den Heap sollte man nur nutzen, wenn es auch wirklich noetig ist. Z.B. bei einer Verwaltung von grossen Mengen an Daten wie Gameobjekte.
Datensaetze, die nicht besonders gross sind oder ohnehin nur temporaer benoetigt werden, sollten auf dem Stack abgelegt werden.
Beim Stack hast du hierbei den Vorteil, dass die Allokierung beim Start einer Prozedur nicht Zeitaufwaendig ist, da der Stack ohne Fragmentierung weiter waechst.
Allokierst du einen Speicherbereich auf dem Heap, muss die Standardlib erstmal einen ausreichend freien Bereich auf dem Heap finden und reservieren, damit es nicht zu Kollisionen kommt. Dazu kommt, dass die Daten manuell wieder freigegeben werden muessen, was frueher oder spaeter zu Memorylecks fuehrt (jeder macht diese Fehler).

Grosse / dynamisch wachsende Datensaetze / verlinkte Listen: Heap
Kleine / temporaere Datensaetze / zeitkritisch: Stack

[KingwondA]

Originally Posted by Actidnoide

Den Heap sollte man nur nutzen, wenn es auch wirklich noetig ist. Z.B. bei einer Verwaltung von grossen Mengen an Daten wie Gameobjekte.
Datensaetze, die nicht besonders gross sind oder ohnehin nur temporaer benoetigt werden, sollten auf dem Stack abgelegt werden.
Beim Stack hast du hierbei den Vorteil, dass die Allokierung beim Start einer Prozedur nicht Zeitaufwaendig ist, da der Stack ohne Fragmentierung weiter waechst.
Allokierst du einen Speicherbereich auf dem Heap, muss die Standardlib erstmal einen ausreichend freien Bereich auf dem Heap finden und reservieren, damit es nicht zu Kollisionen kommt. Dazu kommt, dass die Daten manuell wieder freigegeben werden muessen, was frueher oder spaeter zu Memorylecks fuehrt (jeder macht diese Fehler).

Grosse / dynamisch wachsende Datensaetze / verlinkte Listen: Heap
Kleine / temporaere Datensaetze / zeitkritisch: Stack

Danke für die Antwort.

Wobei ich gerade gelesen habe, dass sogennante Memory Manager helfen sollen Memory-leaks zu finden.
Aber ich bin ganz Deiner Meinung:
Grosse / dynamisch wachsende Datensaetze / verlinkte Listen: Heap
Kleine / temporaere Datensaetze / zeitkritisch: Stack

[MrSm!th]

Der Heap ist langsamer als der Stack, da wirst du wohl etwas falsch verstanden haben.

Du kommst aber nicht um ihn herum, denn du nimmst ihn immer, wenn du Dynamik brauchst, da der Stack gewissermaßen statisch ist (hast du ja schon an den Arrays erkannt).
Du brauchst dich aber selbst gar nicht wirklich mit dem Heap herumschlagen, das tun Klassen für dich. Die Standardlib bringt string für dynamische Zeichenketten, vector für dynamische Arrays und vieles mehr schon mit.

Das Ganze läuft nach dem RAII Prinzip, welches einfach gesagt lautet: Der Konstruktor fordert Speicher an, der Destruktor gibt ihn frei.
Speziell für Pointer gibt es auch noch die Smartpointer, die dieses Prinzip auch in die manuelle Speicheranforderung bringen, solltest du sie einmal brauchen. Damit sind Speicherlecks praktisch ausgeschlossen, denn selbst wenn du deine Daten nicht direkt auf dem sich selbst aufräumenden Stack hast, sind deren Verwaltungsobjekte auf dem Stack. Du musst dieses Prinzip nur konsequent durchziehen.

Grundsätzlich gilt: In deinem Code sollte nirgendwo new oder delete zu sehen sein, es sei denn es gibt einen verdammt guten Grund. Außerdem ist wann immer möglich der Stack direkt zu nutzen. Speicherung auf dem Heap wird durch Klassen gekapselt, deren Objekte wiederum auf dem Stack liegen.

[KingwondA]

Grundsätzlich gilt: In deinem Code sollte nirgendwo new oder delete zu sehen sein, es sei denn es gibt einen verdammt guten Grund. Außerdem ist wann immer möglich der Stack direkt zu nutzen. Speicherung auf dem Heap wird durch Klassen gekapselt, deren Objekte wiederum auf dem Stack liegen.

Ich Zitiere mal etwas aus dem Buch:

Fangen wir mit einem kleinen Rückblick zum Thema Stack und Heap an. Es wurde ja geklärt,
dass lokale Variablen auf dem Stack erzeugt werden. Diese werden gelöscht, nachdem der Gültigkeitsbereich, in dem sie erzeugt wurden, verlassen wird. Das hat den Nachteil, dass wir zum Beispiel Probleme bekommen, wenn wir innerhalb einer Funktion eine Instanz einer Klasse erzeugen, die aber nach Verlassen der Funktion weiterhin gültig sein soll. Globale Variablen kommen als Ausweg nicht infrage, also bleibt nur noch die Möglichkeit, die Klasseninstanz über den Rückgabewert an die aufrufende Funktion zu übergeben. Das ist allerdings recht zeitraubend, da wieder eine komplette Kopie der Instanz auf dem Stack abgelegt werden muss. Erschwerend kommt hinzu, dass man ja nur einen einzigen Rückgabewert zur Verfügung hat. Was bleibt also noch übrig? Nichts!
Oder? Moment, na ja, es gibt ja auch noch den Heap, hätte ich fast vergessen. Wenn man nun also Variablen oder Instanzen einer Klasse auf dem Heap statt auf dem Stack erzeugt, so werden diese nach dem Verlassen einer Funktion nicht mehr automatisch gelöscht. Sie behalten ihr Gültigkeit so lange, bis wir sie selbst wieder freigeben.

-Wichtig-
Daher ich noch ein newbie bin, kenne ich nur die Methoden die mir das Buch liefert, welches ich lese.

[Actidnoide]

Klar, wenn man ein lokales Objekt per Parameter an eine Funktion uebergibt oder als Rueckgabewert zurueckgibt, muss es kopiert werden, was natuerlich etwas mehr Zeit benoetigt.
Es ist aber auch moeglich, ein auf dem Stack liegendes Objekt per Referenz zu uebergeben (Genau wie man es mit dem Heap macht). Der Textausschnitt zeigt keinen wirklichen Geschwindigkeitvergleich zwischen Heap und Stack.

Ich nehme mal an das Buch behandelt auch Zeiger und Referenzen?

[KingwondA]

Originally Posted by Actidnoide

Klar, wenn man ein lokales Objekt per Parameter an eine Funktion uebergibt oder als Rueckgabewert zurueckgibt, muss es kopiert werden, was natuerlich etwas mehr Zeit benoetigt.
Es ist aber auch moeglich, ein auf dem Stack liegendes Objekt per Referenz zu uebergeben (Genau wie man es mit dem Heap macht). Der Textausschnitt zeigt keinen wirklichen Geschwindigkeitvergleich zwischen Heap und Stack.

Ich nehme mal an das Buch behandelt auch Zeiger und Referenzen?

Jop, die habe ich auch mit bravour bestanden.

[Padmak]

Entweder arbeitest du über die von MrSm!th erwähnten Smartpointer, oder du benutzt einen Compiler der den neuesten C++-Standard richtig umsetzt und gibst solche Objekte einfach mithilfe der neuen Move-Semantik zurück.
Wie weit das automatisch gemacht wird, muss dir aber jemand anderes sagen^^

Padmak

[Schlüsselbein]

Objekt nicht dynamisch erstellen und einfach normal zurückgeben. RVO sollte meistens greifen, falls nicht gibt es noch die move semantics oder simples kopieren (was je nach Objekt wirklich kein Problem darstellt).
Falls du beim Testen merkst, dass genau diese Stelle der Flaschenhals ist, kann man nachbessern bzw den komplizierteren Weg gehen.

[MrSm!th]

Originally Posted by KingwondA

Grundsätzlich gilt: In deinem Code sollte nirgendwo new oder delete zu sehen sein, es sei denn es gibt einen verdammt guten Grund. Außerdem ist wann immer möglich der Stack direkt zu nutzen. Speicherung auf dem Heap wird durch Klassen gekapselt, deren Objekte wiederum auf dem Stack liegen.

Ich Zitiere mal etwas aus dem Buch:

Fangen wir mit einem kleinen Rückblick zum Thema Stack und Heap an. Es wurde ja geklärt,
dass lokale Variablen auf dem Stack erzeugt werden. Diese werden gelöscht, nachdem der Gültigkeitsbereich, in dem sie erzeugt wurden, verlassen wird. Das hat den Nachteil, dass wir zum Beispiel Probleme bekommen, wenn wir innerhalb einer Funktion eine Instanz einer Klasse erzeugen, die aber nach Verlassen der Funktion weiterhin gültig sein soll. Globale Variablen kommen als Ausweg nicht infrage, also bleibt nur noch die Möglichkeit, die Klasseninstanz über den Rückgabewert an die aufrufende Funktion zu übergeben. Das ist allerdings recht zeitraubend, da wieder eine komplette Kopie der Instanz auf dem Stack abgelegt werden muss. Erschwerend kommt hinzu, dass man ja nur einen einzigen Rückgabewert zur Verfügung hat. Was bleibt also noch übrig? Nichts!
Oder? Moment, na ja, es gibt ja auch noch den Heap, hätte ich fast vergessen. Wenn man nun also Variablen oder Instanzen einer Klasse auf dem Heap statt auf dem Stack erzeugt, so werden diese nach dem Verlassen einer Funktion nicht mehr automatisch gelöscht. Sie behalten ihr Gültigkeit so lange, bis wir sie selbst wieder freigeben.

-Wichtig-
Daher ich noch ein newbie bin, kenne ich nur die Methoden die mir das Buch liefert, welches ich lese.

Das ist absoluter Unfug. Das Kopieren bei der Rückgabe zu vermeiden, indem man den Heap nutzt? Habe ich ja noch nie gehört. Da killt man den angeblichen Performancevorteil sowieso direkt wieder.
Wie Schlüsselbein schon sagt, jeder aktuelle Compiler optimiert unnötige Kopiervorgänge. Noch dazu gibt es seit C++11 Move-Semantics.
C++ ist nicht Java oder C#, wo (fast) alles nur eine Referenz auf das Objekt auf dem Heap ist. Das ist auch nicht notwendig. Dieser Mythos, in C++ würde zu viel kopiert, ist schon längst Geschichte.
Kauf dir am besten ein anderes Buch. Es enthält mindestens schon einmal veraltete Informationen, wenn nicht sogar falsche.

Originally Posted by Actidnoide

Klar, wenn man ein lokales Objekt per Parameter an eine Funktion uebergibt oder als Rueckgabewert zurueckgibt, muss es kopiert werden, was natuerlich etwas mehr Zeit benoetigt.
Es ist aber auch moeglich, ein auf dem Stack liegendes Objekt per Referenz zu uebergeben (Genau wie man es mit dem Heap macht). Der Textausschnitt zeigt keinen wirklichen Geschwindigkeitvergleich zwischen Heap und Stack.

Ich nehme mal an das Buch behandelt auch Zeiger und Referenzen?

Referenzen auf eine lokale Variable zurückgeben? Schlechte Idee, das ruft undefiniertes Verhalten hervor.

[Actidnoide]

Ich sprach in dem Fall von einer Parameteruebergabe (ja, ging nicht ganz hervor)

[MrSm!th]

Achso, klar, bei Parametern und den meisten anderen Zuweisungen sind natürlich, außer bei primitiven Typen, wann immer möglich Referenzen zu bevorzugen

[KingwondA]

Hmm
Ich bin bei Kapitel 7 von 11.
Soll ich nun hier abbrechen und mir ein besseres Buch zu legen, oder die letzten 4 Kapitel noch zu ende machen, und dann ein neues Buch kaufen?

-Kapitel 7 fehlen mir nur noch 4 neu Sachen (Überschreiben von Memberfunktionen, Virtuelle Memberfunktionen, Vererbung und Performance, Statische Membervariablen), dann wäre ich bei Kapitel 8 und somit würden nur noch 3 Kapitel fehlen......-

Yeah 100 Beiträge ;D

[Elektrochemie]

Würde gern wissen wie es nach dem Zitat aus dem Buch weitergeht. Erscheint mir etwas auseinander "gerupft". :P

Würde das Buch trotzdem noch zuende lesen.