OOP und RAM

[steff3]

ich hab hier 2 klassen klasseA hat einen konstruktor und eine methode in klasseb ist die mainmethode und ein objekt von klasseA
nun soll ich den Arbeitsspeicher während der Programmausführung darstellen

so ich meine es von cpp so zu kennen das dem compiler OOP völlig egal ist und da einfach schneller code generiert wird
wie es der compiler "will"

ist das in java anders ???:L

oder die aufgabe sinnlos :bahnhof:

 

[L-ectron-X]

Ich kann dir nicht ganz folgen. Was willst du machen?
Wie willst du den Arbeitsspeicher darstellen?

Und:
In C++ wie in Java kann man auch langsamen Code schreiben...
Der Compiler "rückt da nichts gerade".

 

[steff3]

ich soll "darstellen" was im Arbeitsspeicher während des erstellen des objekts passiert

 

[L-ectron-X]

Was heißt darstellen? Eine Zeichnung, eine Animation oder einfach nur schriftlich erläutern, was bei einer Instanziierung abläuft?
Sollst du ein Programm schreiben oder einen Text, welcher den Vorgang erläutert?

 

[steff3]

Was heißt darstellen? Eine Zeichnung, eine Animation oder einfach nur schriftlich erläutern, was bei einer Instanziierung abläuft?
Sollst du ein Programm schreiben oder einen Text, welcher den Vorgang erläutert?

vielleicht hätte ich sagen sollen das unser informatik lehrer "anders" ist, nein da steht nicht mehr als darstellen
ka wie

ich denke er will sicher nicht mehr wissen als " da wird speicher reservier, beim erstellen des objekts"

 

[L-ectron-X]

Bei Java wird bei der Objekterzeugung zwar auch Speicher belegt, aber nicht der physikalische Speicher (RAM) wie bei einem nativen Programm sondern Speicher, der von der VM verwaltet wird, also virtueller Speicher. (Den Teil des RAMs, den die JVM für sich beansprucht.) Der Speicherteil, der für Objekte vorgesehen ist heißt Heap.
Der Zugriff auf Objekte erfolgt nicht direkt, sondern über Referenzvariablen.

Auto bmw = new Auto();
//oder:
Auto bmw;
bmw = new Auto();

Hier passiert nun Folgendes:
Auto bmw erzeugt eine Referenz (bmw) die auf ein Objekt der Klasse Auto zeigt.
new Auto() erzeugt ein namenloses Objekt auf dem Heap. Dabei wird der Speicher entsprechend des Datentyps bereitgestellt und belegt.
new gibt eine Referenz (etwas ähnliches wie ein Zeiger in C++) auf das erzeugte Objekt zurück.
Diese Referenz wird in der Referenzvariable bmw gespeichert/zugewiesen.

 

[messi]

Es wäre vielleicht noch erwähnenswert, dass die JVM den Speicherbereich mit Nullen ausfüllt, bevor ein Konstruktur aufgerufen wird.

 

[na-oma]

Wenn du ein String Objekt hast, dann liegt das in einem von den anderen Objekten abgetrennten Bereich "Stringspeicher" oder Symboltabelle haben wir den genannt.
String xyz;
wäre eine Referenz auf diesen Bereich.
Deshalb kann es sein, dass 2 gleiche Strings (zu verschiedenen Zeiten erstellt) auf dem gleichen Speicherbereich abgelegt werden.

String a = "Hallo", b = "Hallo";
würde wahrscheinlich "Hallo" nur einmal anlegen und dann a und b auf die selbe Stelle verweisen lassen.



Was ich mich schon eine Weile frage:

Dass an Methoden übergebene primitive Datentypen (und Referenzen auf Objekte (nicht Objekte selbst!)) auf dem Stack/Keller angelegt werden, nicht auf dem Heap(Halde) ist ja logisch.
Hab ich zumindest so gelesen.

Wo werden allerdings die Attribute eines Objekts gespeichert (welches ja selbst im Heap liegt) ? Im Heap selbst? Irgendwo anders? Wie werden sie dann mit dem Objekt im Heap verbunden?

 

[Guest]

Wo werden allerdings die Attribute eines Objekts gespeichert (welches ja selbst im Heap liegt) ? Im Heap selbst? Irgendwo anders? Wie werden sie dann mit dem Objekt im Heap verbunden?

Die gehören ja zu einem Objekt, daher gehört das alles zusammen. Ein Objekt besteht
nicht nur aus dem Namen. Bei Methoden wird's komplizierter (stichwort VMT). In Java
gibt es aber keinen "richtigen" Stack. Das Programm steckt im Heap der VM und wird
dort interpretiert.

 

[messi]

Wenn du ein String Objekt hast, dann liegt das in einem von den anderen Objekten abgetrennten Bereich "Stringspeicher" oder Symboltabelle haben wir den genannt.
String xyz;
wäre eine Referenz auf diesen Bereich.
Deshalb kann es sein, dass 2 gleiche Strings (zu verschiedenen Zeiten erstellt) auf dem gleichen Speicherbereich abgelegt werden.

String a = "Hallo", b = "Hallo";
würde wahrscheinlich "Hallo" nur einmal anlegen und dann a und b auf die selbe Stelle verweisen lassen.

(Schwache) Referenzen zu String-Objekten werden von der JVM in einer internen Hashtable gehalten, wenn sie als Konstante aus einem Classfile oder mittels String.intern() geladen wurden. Identische String-Konstanten unterschiedlicher Klassen werden also nur einmal als Objekt geladen. Die interne Hashtable unterliegt auch der GC: Strings entladener Klassen werden entfernt, sofern auch sonst keine Referenzen mehr zu ihnen existieren.

Es gibt aber keinen speziellen String-Speicherbereich. Liegt alles auf dem Heap.

In Java gibt es aber keinen "richtigen" Stack. Das Programm steckt im Heap der VM und wird
dort interpretiert.

Selbstverständlich besitzt auch in Java jeder Thread einen eigenen, richtigen Stack. Genaugenommen sogar zwei, weil der Speicherbereich von beiden Enden benutzt wird.

 

[Guest]

In Java gibt es aber keinen "richtigen" Stack. Das Programm steckt im Heap der VM und wird
dort interpretiert.

Selbstverständlich besitzt auch in Java jeder Thread einen eigenen, richtigen Stack. Genaugenommen sogar zwei, weil der Speicherbereich von beiden Enden benutzt wird.

Ich meine das, was in der VM interpretiert wird. Selbstverständlich gibt es einen Stack
in Java (allein schon für Methodenparameter etc.), der wird aber von der VM emuliert.