primitive Datentypen, String, Klassen

[Fellkneul]

hallo,

ich habe folgende Frage:

Wenn ich eine Variable eines primitiven Datentypes definiere, dann wird dort direkt eine Information gespeichert.

BSP:

int a = 5;

dann steht in der Variable einfach nur "5"


Wenn ich eine Variable vom Typ Object o.ä. habe, dann wird dort drin der Verweis auf die Instanz einer Klasse gespeichert.

BSP:

Object x = new Object();

dann steht in x ein Verweis auf das soeben erstellt Object...



aber: wie ist das bei Strings? der String ist ja eigentlich eine Klasse, und kein primitiver Datentyp. "String" hat eigene Eigenschaften und Funktionen. Das bedeutet, dass wenn ich schreibe:

String a = "MuhMuh";

dann steht in a eigentlich auch nur ein Verweis auf die Instanz eines Strings und nicht "MuhMuh". Wenn ich jetzt schreibe:

String b = a;

und dann irgendwie die Instanz, die in a gespeichert ist verändere (also nicht a einen neuen String zuweise, sondern genau den String, auf den a zeigt, verändere), dann müsste sich doch auch b verändern, richtig??



vielen Dank für die Mühe,

gruß,
Fellkneul

 

[diggaa1984]

(also nicht a einen neuen String zuweise, sondern genau den String, auf den a zeigt, verändere

Strings sind unveränderlich, jede "Änderung" impliziert die Erstellung eines neuen Strings

 

[ARadauer]

String a = "MuhMuh";
ist eignetlich eine Kurzform für

String a = new String("MuhMuh");

und dann irgendwie die Instanz, die in a gespeichert ist verändere (also nicht a einen neuen String zuweise, sondern genau den String, auf den a zeigt, verändere), dann müsste sich doch auch b verändern, richtig??

grundsätzlich ja, aber einen string kannst du nicht verändern. der ist immutable, er bietet dir keine möglichkeit in zu ändern...

 

[maki]

dann steht in der Variable einfach nur "5"

Ja.

dann steht in x ein Verweis auf das soeben erstellt Object...

Auch richtig.

aber: wie ist das bei Strings?

String sind sog. immutables, unveränderlich, jede Operation die den String verändern soll leifert ein neues Objekt zurück, so vermeidet man Aliasing Probleme, suche mal nach immutable.

 

[Fellkneul]

danke, danke

hab schon verstanden. leuchtet mir alles ein...

 

[Wildcard]

String a = "MuhMuh";
ist eignetlich eine Kurzform für

String a = new String("MuhMuh");

Und

String a = new String("MuhMuh");

Ist eine Kurform von

String a = new String(new String("MuhMuh"));

?

 

[musiKk]

String a = "MuhMuh";
ist eignetlich eine Kurzform für

String a = new String("MuhMuh");

Fatale Aussage im Anfängerforum. Das impliziert ja, dass die beiden Zeilen gleich sind...

 

[Spacerat]

Ich fürchte, musiKk hat vollkommen recht. Ein Anfängerforum ist kaum der richtige Platz für solche witzeleien. Zumal die Tragweite des ganzen leicht unübersehbar werden kann.[highlight=java]StringBuffer tmp = new StringBuffer();
for(int n = 0; n < 10000; n++) tmp.append("a");
String ramkiller = tmp.toString().subString(44, 2);[/highlight]Wer hier annimmt, dass dass interne Char-Array von "ramkiller" blos 2 Elemente hat, irrt gewaltig. Wenn man daraus dann öffters noch[highlight=java]String ramkiller_x = new String(ramkiller);[/highlight]macht, ist der Speicher schneller futsch als man denkt.

 

[SchonWiederFred]

Wenn man daraus dann öffters noch[highlight=java]String ramkiller_x = new String(ramkiller);[/highlight]macht, ist der Speicher schneller futsch als man denkt.

Wieso das denn? Es gibt zwei Möglichkeiten:

1. Der neue String teilt sich das Array mit dem alten String -- das große Array existiert also weiterhin nur einmal
2. Der neue String macht sich sein eigenes, kleineres Array -- dann gibt es ein großes und ein kleines Array

In meiner Implementation handelt es sich um Möglichkeit 2:

if (originalValue.length > size)
{
    // The array representing the String is bigger than the new
    // String itself.  Perhaps this constructor is being called
    // in order to trim the baggage, so make a copy of the array.
    int off = original.offset;
    v = Arrays.copyOfRange(originalValue, off, off+size);
}
else
{
    // The array representing the String is the same
    // size as the String, so no point in making a copy.
    v = originalValue;
}

 

[Noctarius]

String a = "MuhMuh";
ist eignetlich eine Kurzform für

String a = new String("MuhMuh");

Eigentlich ist das die Stringinstanz für den Test "MuhMuh" aus dem StringConstantPool

Das erklärt wieso eine zweite String-Referenz z.B. String b = "MuhMuh" die selbe Instanz liefern würde. Konstante Strings hält Java im internen ConstantPool vor.

 

[Spacerat]

@SchonWiederFred: Wieso? Recht einfach: "ramkiller_x" erhält mit jeder Instanz definitiv ein eigenes Char-Array (copy). Bei zwei Zeichen scheint das kaum was auszumachen. Strings sind in Java aber nicht blos Char-Arrays, sondern enthalten zusätzlich noch Länge und Offset. Und jede neue Instanz eines jeden Java-Objekts hat einen Overhead der nicht zu unterschätzen ist. Ein String mit 2 Zeichen belegt hier jedenfalls weit mehr als 8 (2x char) Bytes.
@Noctarius: Natürlich. Bei gleichen Strings ist's egal.

 

[Noctarius]

@Noctarius: Natürlich. Bei gleichen Strings ist's egal.

Eben deswegen ist es keine Kurzform für 'new String("MuhMuh")'

 

[maki]

Auf jedenfall ist new String(..) bääh und keine kurzform für irgendetwas anderes!

FindBugs findet solche Patzer übrigens ohne weiteres.

 

[SchonWiederFred]

@SchonWiederFred: Wieso? Recht einfach: "ramkiller_x" erhält mit jeder Instanz definitiv ein eigenes Char-Array (copy). Bei zwei Zeichen scheint das kaum was auszumachen.

Ja, weil Du auf Teufel komm raus ein furchtbares Programm geschrieben hast. Wenn Du das toString() beim StringBuffer weglässt, sieht es wahrscheinlich schon viel besser aus.

Aber zeige mir bitte ein Programm, dass einige Tausend mal gleiche, neue Strings erzeugt. Ist mir noch nie untergekommen. Immer diese Panikmache

Wenn Dich der Objekt-Overhead generell stört, nimm C++.

 

[maki]

Denke dass wir uns alle darauf einigen können dass Copy-Konstruktoren und deren Aufruf bei immutables keine gute Sache ist, dass diese überhaupt existieren sind Altlasten.
Wie schlecht das dann wirklich ist imho sekundär.

Dass gilt für String genauso wie für Integer und natürlich alle anderen immutables.

 

[Spacerat]

@SchonWiederFred: Auf Teufel komm raus...! Klar... Irgendwie muss man die Problematik doch schliesslich in ein KSKB bringen. Mit einem Programm, welches n-mal den selben kurzen String aus einem Langen zieht, kann ich auch nicht dienen. Aber 1000 verschiedene Kurze aus einem Langen, ist ein gern genommener Anfängerfehler (z.T. sind auch noch Fortgeschrittenere davon betroffen). Wir wissen glücklicherweise, das so etwas mit StringBuffer oder StringBuilder viel effizienter geht.
Deswegen:
@maki: Ich denke, du hast recht ^^.

 

[Wildcard]

new String("some string") sollte eigentlich ebenso wie "some string".intern() Konstanteninlining verhindern und hätte damit schon einen praktischen Nutzen. In wie weit das seit enums noch gebraucht wird ist allerdings wieder eine andere Frage.