String ausleeren

[n0n3]

Hi,
kann ich einen String ausleeren, sodass ich ihn neu füllen kann, also praktisch komplett neu definieren. z.B. so:

String meinString = "Ich bin ein String";
meinString.leeren(); // also irgendwas was dem String den Wert "" gibt
meinString = "Blablabla";

Der String kann auch überschrieben werden, wenn das möglich ist. Am besten ohne StringBuffer oder -Builder.

 

[André Uhres]

..meinString.leeren(); // also irgendwas was dem String den Wert "" gibt..

Dann gib doch einfach dem String diesen Wert "".

meinString = "";

Oder gib dem String direkt den neuen Wert, wird eh ein neuer String erzeugt.

 

[n0n3]

Ups so einfach ^^
Mal wieder viel zu kompliziert gedacht

[schild=11 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]Danke[/schild]

 

[Der_Unwissende]

Hi,
das klappt zwar genau so wie es dort steht, aber Strings sind auch nur Klassen. Genau genommen gibt es hier ein paar Besonderheiten, du arbeitest bei Strings immer mit unveränderlichen Instanzen.
Wenn du etwas hast wie

String s = "Bla";
s = "";
s = "Blubb";

Dann legst du hier 3 Instanzen eines Strings an. Das kostet einfach ein wenig Rechenzeit (anlegen eine neuen Instanz, alte Referenz frei geben). Wenn du also weißt, dass du etwas an einem String ändern möchtest und keine all zu speziellen Eigenschaften eines Strings benötigst, empfiehlt sich eher der griff zu StringBuffer oder StringBuilder (die sind variabel und können dir natürlich auch wieder einen String liefern).

Gruß Der Unwissende

 

[Guest]

Nö das geht schon. Habs versucht, kein Unterschied von der Rechendauer oder so

 

[André Uhres]

..Dann legst du hier 3 Instanzen eines Strings an. Das kostet einfach ein wenig Rechenzeit (anlegen eine neuen Instanz, alte Referenz frei geben)..

Drei Strings muss ein Programm doch verkraften können, nicht wahr?
Übrigens gibt's bei StringBuffer auch ne Falle: wenn man den append macht mit:

buf.append("["+ idx +"]"+ array[idx]);

dann wird durch den + Operator intern wieder ein neuer StringBuffer angelegt,
was dann wieder zu schlechter Performance (z.B.in einer Schleife) führen kann. Besser wäre in dem Fall:

buf.append("[");
buf.append(idx);
buf.append("]");
buf.append(array[idx]);

 

[byte]

Drei Strings muss ein Programm doch verkraften können, nicht wahr?

Wohl wahr. Und wir sind hier nicht im C++ Forum, wo um jede Nanosekunde Laufzeit gekämpft wird. :roll:

 

[Leroy42]

Besser wäre in dem Fall:

buf.append("[");
buf.append(idx);
buf.append("]");
buf.append(array[idx]);

Und (vielleicht) noch besser die Benutzung des aus Smalltalk
bekannten Kaskadierens

buf.append("[")
   .append(idx)
   .append("]")
   .append(array[idx]);

Das append die Instanz zurückliefert auf die es angewandt wurde
kommt ja nicht von ungefähr. (Sollte es übrigens viel öfter geben
als das ansonsten sinnentleerte void als Rückgabetypen )

 

[André Uhres]

..Und (vielleicht) noch besser die Benutzung des aus Smalltalk
bekannten Kaskadierens..

Ist gut zu wissen :toll: , für die Performance stellt das imho aber keine Verbesserung dar?

 

[Leroy42]

..Und (vielleicht) noch besser die Benutzung des aus Smalltalk
bekannten Kaskadierens..

Ist gut zu wissen :toll: , für die Performance stellt das imho aber keine Verbesserung dar?

Aber auch keinen Nachteil:

Im Gegensatz zu C weiß der Java-Compiler immer welchen Rückgabetyp eine
Methode hat; deshalb erübrigt sich eine Rückgabe der Instanz (wie z.B. bei C auf
dem Stack), da der Compiler selbst ja weiß

Rückgabetyp void ==> Objekt dessen Methode aufgerufen wurde ist Rückgabe.

Meiner Meinung nach ein Designfehler den ich zu Anfang (Smalltalk --> Java)
schmerzlich vermißte.

 

[André Uhres]

Ich glaub jetzt ist's wieder die Hitze, deine letzten vier Zeilen gehen mit mir durch..

 

[Leroy42]

deine letzten vier Zeilen gehen mit mir durch..

:shock: Ish nix ausländish verstehen :shock:

Was meinst du mit: "gehen mit mir durch"?

 

[André Uhres]

..Was meinst du mit: "gehen mit mir durch"?

Hehe, keine Ahnung
Ist halt für mich genauso unverständlich wie das hier:

..da der Compiler selbst ja weiß

Rückgabetyp void ==> Objekt dessen Methode aufgerufen wurde ist Rückgabe.

Meiner Meinung nach ein Designfehler den ich zu Anfang (Smalltalk --> Java)
schmerzlich vermißte.

 

[Leroy42]

In Smalltalk gibt es keinen void-Rückgabetypen.
Methoden die explizit kein return (^42) haben geben
immer den Aufgerufenen zurück.

Da dies immer geschieht, weiß das der Compiler
und er kann bei Kaskaden wie (nach Java transformiert)

JFrame meinElendLangerVariablenName = new JFrame();

meinElendLangerVariablenName
   .setTitle("...")
   .setLayout(new FlowLayout())
   .setBounds(...)
   .setWindowListener(...)
   .setVisible(true);

die Aufruffolge generieren ohne daß irgendeine Methode
irgendetwas auf den Return-Stack packen muß.

 

[André Uhres]

Ach so, ich dachte du sprichst von Java-Compiler, weil du den grad vordran erwähnst. Aber dass du einen Designfehler schmerzlich vermisst, also ich bin immer froh wenn kein Fehler da ist.

 

[Leroy42]

Ach so, ich dachte du sprichst von Java-Compiler, weil du den grad vordran erwähnst. Aber dass du einen Designfehler schmerzlich vermisst, also ich bin immer froh wenn kein Fehler da ist.

:shock: LOL :applaus:

Das es ausgerechnet mich auch mal erwischen muß ist
eigentlich nur gerecht!

Du führst 1:0

 

[André Uhres]

Naja, schieben wir's auf's Wetter. Dein Onkel scheint wirklich das grosse Los gezogen zu haben, mit Sibirien..