ich hab mal ne grundlegende Frage: Was ist der entscheidende Vorteil, wenn man ein Oblekt nicht mit

<Klasse> <Objekt>;

, sondern mit

<Klasse> *<Objekt>=new <Klasse>;

definiert? Vllt. habt ihr sogar ein Bsp., wo es nur mit der Variante mit new geht, um den Vorteil zu erkennen?

Durch die dynamische Erzeugung mit den new Operator hast du dir ein Nachteil eingekauft: Du musst dich um die Freigabe des Speicherplatzes selber kümmern.

Man benutzt den new Operator, wenn erst zur Laufzeit des Programms die Anzahl der zu erstellenden Objekte bekannt ist.

ich tue mich schwer, "Vorteile" zu nennen .. es sind eher "Eigenschaften" von Heapobjekten. Spontan fallen mir ein:

• Erzeugung und Lebenszeit nicht an Scopes gekoppelt,
• üblicherweise steht auf dem Heap mehr Platz zur Verfügung.

... wie schon gesagt: Wenn Du mehrere Objekte (desselben Typs) anzulegen hast, kannst Du hier freier entscheiden, wie viele Du erzeugen möchtest als bei einem "klassischen Array". (aber "dynamischer" als ein std::vector ist das auch nicht ... allerdings nutzt der intern bestimmt auch new da wird's dann philosophisch)

Gruß,

Simon2.

Der Stack dagegen wird sozusagen automatisch Verwaltet:
Beim Eintritt in eine Funktion werden die Variablen, Parameter etc. automatisch auf den Stack gelegt, d.h. es wird Speicherplatz reserviert. Beim Verlassen der Funktion wird der dafür benötigte Speicherplatz automatisch freigegeben.

Ich würde da nichts genau definieren wollen. Ob Stack oder Heap, beides ist Arbeitsspeicher, jedoch mit unterschiedlichem Verhalten.

...bis du den Speicher mit new oder new [] freigibst.....

Fehlerteufelchen sagt: "...delete oder delete [] ..."

Gruß,

Simon2.

Der feine Unterscheid schrieb:

...bis du den Speicher mit new oder new [] freigibst.....

Fehlerteufelchen sagt: "...delete oder delete [] ..."

Gruß,

Simon2.

Fehlerteufelchen hat völlig Recht !

Darum EDIT:
"...bis du den Speicher mit delete oder delete [] freigibst.....

...
Fehlerteufelchen hat völlig Recht !...

Naja, war auch nicht wirklich schwer. War vermutlich jedem klar, was Du meintest, aber ich wollte es nur für den ungeübten Leser klarstellen.
Ach ja: Inhaltlich stimme ich Dir natürlich voll zu.

Gruß,

Simon2.

void funk(){

  int i;

}

somit lebt i ab "int i" bis zum ende des funktionsblocks.

wobei bei:

void funk(){

int *i= new int();

}

ein int aufm heap angelegt wird, und über die funktion hinaus lebt, bis"delete bis "delete i;" aufgerufen wird... wichtig dabei ist, das man sich die adresse des aufm heap angelegen int's also der pointer i, sich solange merkt bzw. man damit den int wieder löscht.

int main(){

int *i= new int();

i = NULL;

}

dass ist dieser new-integer für immer verschollen!!!!!

Naja daten aufm Stack existiert ja nicht von anfang bis zum ende des Programmes (auser vll. Global oder static) , sondern nur so lange wie sie das Programm zu laufzeit in einen best Block (in der die variable deklaiert wird) arbeitet bspw. funktion..

Nur am Rande: globale und statische Variablen liegen nichtmal auf dem Stack (sondern im Data Segment)

wobei bei:

void funk(){

int *i= new int();

}

ein int aufm heap angelegt wird, und über die funktion hinaus lebt, bis"delete bis "delete i;" aufgerufen wird... wichtig dabei ist, das man sich die adresse des aufm heap angelegen int's also der pointer i, sich solange merkt bzw. man damit den int wieder löscht.

So, wie du die Funktion geschrieben hast, ist das aber kein Beispiel für den richtigen Umgang mit dem Heap
Das int-Objekt liegt auf dem Heap und überlebt damit das Funktionsende. Der int-Zeiger liegt auf dem Stack und geht am Ende der Funktion verloren - ergo hast du ein sauberes Speicherleck.

PS: Ja, die meisten Betriebssysteme holen sich allen angeforderten Heap-Speicher zurück, wenn dein Programm sich beendet, aber (a) können RL-Anwendungen etwas länger laufen und (b) werden auf diesem Weg keine Objekt-Destruktoren mehr aufgerufen (das Ergebnis sind im Ernstfall weitere Lecks, die häufig außerhalb des OS-Einflußes liegen).

und trozdem ist da der stack begrenzt?

war frühr der stack nich driekt auf der CPU im cache oder so?

was für ne kapazität hat stack?

war frühr der stack nich driekt auf der CPU im cache oder so?

es gibt verschiedene arten von stacks.
für gewöhnlich haben CPUs mindestens einen stackpointer (ein internes register), den sie automatisch runterzählen, um die rücksprungadresse zu speichern wenn eine funktion aufgerufen und wieder hoch, wenn die funktion verlassen wird.
zusätzlich legen viele compiler für lokale variablen sogenannte stackframes an. dabei wird z.b. sizeof(alle_lokalen_variablen) vom stackpointer abgezogen und beim verlassen der funktion wieder dazu addiert.
...und meistens 'wachsen' solche stacks von oben nach unten.

stack und heap sind beides aufm Arbeitspeicher oder?
und trozdem ist da der stack begrenzt?
...

Muss ja begrenzt sein, weil doch der Arbeitsspeicher aus physikalischen Speicherzellen besteht, also reale Hardware ist.
Kennst doch die SD-RAM- oder DDR-RAM-Speicherriegel ?

BorisDieKlinge schrieb:

stack und heap sind beides aufm Arbeitspeicher oder?
und trozdem ist da der stack begrenzt?
...

Muss ja begrenzt sein, weil doch der Arbeitsspeicher aus physikalischen Speicherzellen besteht, also reale Hardware ist.
Kennst doch die SD-RAM- oder DDR-RAM-Speicherriegel ?

naja, stack-speicher von usermode prozessen können moderne betriebssysteme aber auch auslagern...

...
naja, stack-speicher von usermode prozessen können moderne betriebssysteme aber auch auslagern...

Wo wollen die damit denn hin ?

pale dog schrieb:

...
naja, stack-speicher von usermode prozessen können moderne betriebssysteme aber auch auslagern...

Wo wollen die damit denn hin ?

irgendwo auf'n massespeicher, festplatte, paging file, swap partition...

Auserdem wollte ich damit sagen, das die größe der Arbeitspeichers (heute Zeit) im Verhältnis zum reserviern Stack ja enorm ist .. und bei massenspeichern noch ernomer... und mich deshalb frage wieso nur ein winziger teil für den stack benutzt wird... so das wars:)

Und ja ich hatt sogar schonmal so ein Speicherriegel als Schlüsselanhänger;)