Ich bin etwas verwirrt über die Definition von Lebensdauer
und Bindungsbereich im P2-Skript.

Und zwar steht dort:

Lebensdauer bezeichnet allgemein die Zeit,
in der ein Objekt unter dem ihm zugewiesenen Bezeichner,
existiert.

Das wundert mich schonmal. Meine bisherige Vorstellung von
Lebensdauer war eher, dass das eine Eigenschaft eines Objekts
ist. Wenn also ein Objekt einen anderen zusätzlichen Bezeichner
bekommt (indem es als Attribut irgendwoanders nochmal referenziert
wird) und der alte Nach dem Ende der Methode nicht mehr sichtbar
ist, hätte ich gedacht, das Objekt befinde sich noch in seiner
Lebensdauer. Nach Definition tut es das aber nicht (oder irre
ich mich da?).

Meine Vorstellung entspräche also eher der Formulierung
"die Zeit, in der ein Objekt unter einem ihm
zugewiesenen Bezeichner existiert". Oder ist das so
gemeint? (Außerdem kann doch überhaupt nicht von dem
ihm zugewiesenen Bezeichner sprechen, höchstens von
dem, dem das Objekt bei der Erzeugung zugewiesen wurde;
und so hatte ich das interpretiert).

Weiter unten auf der Folie wird dann wieder geschrieben,
die Lebensdauer eines Objekts hänge zusammen mit dem
Bindungsbereich "seines" Bezeichners. Auch hier wird
wieder implizit angenommen, ein Objekt habe einen eindeutigen
Bezeichner.

Ich habe eine Skript-Version vom SoSe 2001 (auf der
Seite keine neuere Version gefunden). Gibt es im Netz
irgendwo eine neuere Version? Wie ist die Lebensdauer im
aktuellen Skript definiert? Wo ist mein Denkfehler?

Lebensdauer bezeichnet allgemein die Zeit,
in der ein Objekt unter dem ihm zugewiesenen Bezeichner,
existiert.

Ich denke, dass es auf die jeweilige Sprache ankommt. Aber die Grundidee ist die o.g. Defintion.

In Java gibt es keine Möglichkeit ein Objekt explizit zu löschen. Nur der Garbage Collector löscht das Objekt, sofern das Objekt nicht mehr referenziert wird. Daher trifft sowohl die Definition als auch Dein Gedanke zu.

In C++ z.B. kannst Du ein Objekt explizit löschen (auch wenn es referenziert worden ist - wenn es gelöscht wird und noch referenziert ist, entstehen andere Probleme…). Daher existiert das Objekt so lange der Bezeichner existiert.

Lebensdauer bezeichnet allgemein die Zeit,
in der ein Objekt unter dem ihm zugewiesenen Bezeichner,
existiert.

In Java gibt es keine Möglichkeit ein Objekt explizit zu löschen. Nur der Garbage Collector löscht das Objekt, sofern das Objekt nicht mehr referenziert wird. Daher trifft sowohl die Definition als auch Dein Gedanke zu.

In C++ z.B. kannst Du ein Objekt explizit löschen (auch wenn es referenziert worden ist - wenn es gelöscht wird und noch referenziert ist, entstehen andere Probleme…). Daher existiert das Objekt so lange der Bezeichner existiert.

Ja, in C++ stimmt die Lebensdauer (nach der Definition und meiner
Vorstellung) nicht mit der Zeit überein, in der Speicher für ein
Objekt alloziiert ist. Soweit ist das klar. Die Frage ist nur:
Wenn für ein Objekt ein neuer Bezeichner angelegt wird und der
alte ungültig wird, ist es komischerweise nach der Definition
außerhalb seiner Lebensdauer:


public class Beispiel { private String name; public Beispiel() { String standardName="Max Mustermann"; this.name=standardName; } }
Ist dann nach Ausführung des Konstruktors die Lebensdauer
des Strings mit dem Inhalt "Max Mustermann" überschritten,
nur weil man nun einen anderen Bezeichner hat?
Was ist hier der Bezeichner? In C++ besteht das Problem
genauso.

Edit: Ich sehe gerade: auf der nächsten Folie steht
außerdem, dass Lebensdauer der Zeitraum sei, in der einer
Variablen Speicherplatz zugewiesen ist. Wenn man das so sieht
(und Variable als Objekt versteht), ist der Begriff
wenigstens wohldefininiert (weil nicht mehr von dem Bezeichner
die Rede ist). Die Definition stimmt dann zwar nicht immer mit der
ersten überein (erstens im Codebeispiels und zweitens
in C++), aber damit kann man wohl leben (d.h. in die Prüfung
gehen [img]http://www.fb18.de/gfx/10.gif[/img]).
Vielleicht war das auch das, was du mir mit deinem Posting sagen
wolltest. Danke jedenfalls [img]http://www.fb18.de/gfx/23.gif[/img]

Ja, in C++ stimmt die Lebensdauer (nach der Definition und meiner
Vorstellung) nicht mit der Zeit überein, in der Speicher für ein
Objekt alloziiert ist. Soweit ist das klar. Die Frage ist nur:
Wenn für ein Objekt ein neuer Bezeichner angelegt wird und der
alte ungültig wird, ist es komischerweise nach der Definition
außerhalb seiner Lebensdauer:


public class Beispiel { private String name; public Beispiel() { String standardName="Max Mustermann"; this.name=standardName; } }
Ist dann nach Ausführung des Konstruktors die Lebensdauer
des Strings mit dem Inhalt "Max Mustermann" überschritten,
nur weil man nun einen anderen Bezeichner hat?
Was ist hier der Bezeichner? In C++ besteht das Problem
genauso.

Hmmhmm. So ganz weiß ich noch nicht wohin Du gehen möchtest…

private String name;
(Der Bezeichner ist <name>)

String standardName="Max Mustermann";
(Der Bezeichner ist <standardName>)

this.name=standardName;
Nun referenziert name auf standardName. Wenn der Konstruktor abgearbeitet worden ist, existiert standardName weiterhin, da noch eine Referenz existiert - der Garbage Collector loescht standardName noch nicht.

Hmmhmm. So ganz weiß ich noch nicht wohin Du gehen möchtest…

private String name;
(Der Bezeichner ist <name>)

String standardName="Max Mustermann";
(Der Bezeichner ist <standardName>)

this.name=standardName;
Nun referenziert name auf standardName.

Naja, er referenziert eigentlich das Objekt hinter standardName.

Wenn der Konstruktor abgearbeitet worden ist, existiert standardName weiterhin, da noch eine Referenz existiert - der Garbage Collector loescht standardName noch nicht.

Nein, hier liegt (lag, siehe mein Edit) genau das Problem:
Wenn der Konstruktor abgearbeitet worden ist, existiert zwar
das Objekt, auf das standardName vorher verwiesen hat, weiterhin,
aber der Bezeichner standardName nicht mehr.

Ich glaube wir reden das gleiche…

dass Lebensdauer der Zeitraum sei, in der einer
Variablen Speicherplatz zugewiesen ist

Genau das meinte ich :-)

Und ich meinte auch Referenz auf das Objekt.


Aber ich denke wir haben das Problem nun geklärt.
Viel Spaß noch.