Lebensdauer von Objekten

mabo42

Wenn Du unskilled bist, was muß ich dann sein ???

Vielen Dank für Deine Erklärung

Skym0sh0

mabo42 schrieb:

#include <windows.h>
#include <string>
#include <sstream>

using namespace std;

string Format(int value)
{
  stringstream s;      // hier wird ein stringstream-Objekt auf dem lokalen Stack angelegt
  s << value;          // hier wird es benutzt
  return s.str();      // und hier sollte es doch wieder zerstört werden,
                       // nachdem seine Memberfunktion str() ein string-Objekt erstellt hat
} // es wird hier zerstört und der destruktor aufgerufen

int main()
{
  MessageBox(NULL, Format(17).c_str(), "", 0);  // Anzeige erscheint korrekt 
  return 0;
}

man kann sich das ganz einfach merken
ein objekt (variable etc) ist solange existent bis zu der nächsten schliessenden klammer '}'
mh schlecht ausgedrück, beispiel:

int main()
{
   int a;
   {
       int b;
       {
            int c;
       } // c wird zerstört hier, alles andere ist noch gültig
   }// b wird hier zerstört, a ist noch gültig
} // nun wird auch a zerstört

für zeiger gilt das selbe, nur nicht für das auf was sie zeigen...

drakon

ein objekt (variable etc) ist solange existent bis zu der nächsten schliessenden klammer '}'

Dann leben die Objekte in Klassen aber nicht sehr lange..
Und was ist mit Speicher, welcher nicht automatisch behandelt wird?

unskilled

drakon schrieb:

ein objekt (variable etc) ist solange existent bis zu der nächsten schliessenden klammer '}'

Dann leben die Objekte in Klassen aber nicht sehr lange..
Und was ist mit Speicher, welcher nicht automatisch behandelt wird?

was bringt es dir, seinen beitrag mit absicht falsch zu interpretieren?
ist ja offensichtlich, in welchem zusammenhang er das mit der schließenden klammer meinte... (womit sich das mit den membern erledigt hätte)
und was willst du mit speicher der nicht automatisch behandelt wird?
es ging um objekte... d.h. die frage richtete sich nach der zerstörung des objektes - egal, wie diese aussieht... und die zerstörung von PODs ist nun mal nur den bezeichner ungültig zu machen und die paar byte, auf die er verweist freizugeben...

{
int *a = new int[123];
} //[ a ] wird zerstört - NICHT [ *a ]

bb

drakon

Skym0sh0 schrieb:

man kann sich das ganz einfach merken
ein objekt (variable etc) ist solange existent bis zu der nächsten schliessenden klammer '}'

Weil es so schlichtweg falsch ist und wir fangen hier nicht an irgendwelche falsche Tatsachen zu verbreiten..

Natürlich stimmt es in diesem gezeigtem Fall, aber das ist noch lange kein Grund eine so falsche Aussage loszulassen. Die Lebensdauer von Objekten hängt von vielen Sachen ab und kann nicht so pauschalisiert werden. Die Lebensdauer von lokalen, nicht-statische Objekte wird von den schweifenden Klammern bestimmt ja, aber da hört das auch schon auf. Es gibt z.B auch noch statische Variablen, die anderst behandelt werden. (und das ist für gewisse Sachen dann keine zu vernachlässigendes Problem, siehe Singleton).

es ging um objekte... d.h. die frage richtete sich nach der zerstörung des objektes - egal, wie diese aussieht... und die zerstörung von PODs ist nun mal nur den bezeichner ungültig zu machen und die paar byte, auf die er verweist freizugeben...

Und wenn man Speicher dynamisch anfordert, dann werden dan keine Objekte erzeugt?! Und seit wann kann man POD's nicht dynamisch erzeugen?

@drakon:
Du vergleichst da Äpfel mit Birnen. Bei einer Klassendeklaration wird nichteinmal Speicher alloziiert, wäre also nichts, was überhaupt "leben" könnte. Instanzen von Klassen hingegen leben ja auch wirklich nur (gehen wir nicht von den folgenden Spezialfällen aus) im jeweiligen Block, in dem sie deklariert wurden.
Bezüglich dynamisch alloziiertem Speicher:
Wenn man Speicher explizit per new anfordert sollte es klar sein, ihn auch explizit per delete wieder freizugeben.

Statische und globale Variablen etc. sind wohl offensichtliche Ausnahmefälle.
Aber im Moment geht es wohl um stinknormale Objekte die in Funktionen auf dem Stack erzeugt werden.
Und dafür ist die regel eigentlich in ordnung, oder zumindest eine kleine Orientierungshilfe.

drakon schrieb:

Und wenn man Speicher dynamisch anfordert, dann werden dan keine Objekte erzeugt?! Und seit wann kann man POD's nicht dynamisch erzeugen?

Du hast wohl seinen Post nicht komplette gelesen:

Skym0sh0 schrieb:

man kann sich das ganz einfach merken
ein objekt (variable etc) ist solange existent bis zu der nächsten schliessenden klammer '}'
....
für zeiger gilt das selbe, nur nicht für das auf was sie zeigen...

Völlig korrekt diese Aussage!
Die hälfte des Threads wegen dir ziemlich sinnlos.

hustbaer

Irgendwie wundert mich dass noch keiner darauf hingewiesen hat dass es hier um ein Temporary geht. Und das stirbt vereinfacht gesagt beim nächsten ";".
Wo der aktuelle Scope endet spielt dabei keinen Walzer.
Beispiel:

std::string foo()
{
    return bar(); // was auch immer
}

void test()
{
    std::string baz;
    baz = foo(); // Der Returnwert von foo() stirbt hier, nicht erst nach tu_nochwas()!
    tu_nochwas();
}

drakon

NoScoper schrieb:

@drakon:
Du vergleichst da Äpfel mit Birnen. Bei einer Klassendeklaration wird nichteinmal Speicher alloziiert, wäre also nichts, was überhaupt "leben" könnte. Instanzen von Klassen hingegen leben ja auch wirklich nur (gehen wir nicht von den folgenden Spezialfällen aus) im jeweiligen Block, in dem sie deklariert wurden.

Um das geht es ja. Aber wenn man sagt, dass "eine Variable so lange lebt bis zum nächsten }", dann gibst du mir mit dieser Aussage ja Recht, da nach der Deklaration in der Klasse das nächste } die Objekte nicht zerstört, sondern erst im dtor.
Im übrigen meinst du im letzten Satz die Definition und nicht die Deklaration..

Bezüglich dynamisch alloziiertem Speicher:
Wenn man Speicher explizit per new anfordert sollte es klar sein, ihn auch explizit per delete wieder freizugeben.

Wenn du einem Neuling sagst, dass der Speicher beim nächsten } wieder freigegeben wird und der dann etwas mit new macht, ist das für ihn nicht so klar.

Statische und globale Variablen etc. sind wohl offensichtliche Ausnahmefälle.
Aber im Moment geht es wohl um stinknormale Objekte die in Funktionen auf dem Stack erzeugt werden.
Und dafür ist die regel eigentlich in ordnung, oder zumindest eine kleine Orientierungshilfe.

hustbaer schrieb:

Irgendwie wundert mich dass noch keiner darauf hingewiesen hat dass es hier um ein Temporary geht. Und das stirbt vereinfacht gesagt beim nächsten ";".

Stimmt. Daran habe ich nicht einmal gedacht.

Man sollte sich die Lebensdauer von Objekten nicht so auf die leichte Schulter nehmen. Und auch die Reihenfolge der Initialisierung kennen. (vor allem in Klasssen kann das sehr ärgerliche Fehler geben..)

Nexus

drakon schrieb:

Man sollte sich die Lebensdauer von Objekten nicht so auf die leichte Schulter nehmen.

Besonders, wenn dann noch Sonderfälle wie an Const-Referenzen gebundene Temporaries ins Spiel kommen. So ganz trivial ist die Sache nicht...