Hi ,
ich frage den Wert eines Textfeldes ab.
Wenn nichts drinsteht, soll laut doku JDK 1.2.2 ein leerer String ("") zurückgegebn werden.
Diesen frage ich mit
if( MeinString==""||MeinString==null)
ab.
Leider klappt das nicht!
Warum nicht? Hat jemand eine (bessere) Idee?
bis dann ,
Jan
Hi ,
ich frage den Wert eines Textfeldes ab.
Wenn nichts drinsteht, soll laut doku JDK 1.2.2 ein leerer
String ("") zurückgegebn werden.
Diesen frage ich mit
if( MeinString==""||MeinString==null)
ab.
Leider klappt das nicht!
Warum nicht? Hat jemand eine (bessere) Idee?
Ja,
versuchs mal mit
MeinString.equals("")
Hallo,
versuchs mal mit
MeinString.equals("")
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.
Nicht sollte! Das geht nur so!!!
Ich würde noch folgendes machen:
if( (MeinString!= null) && (MeinString.equals("")) )
...
Wenn man das umgekehrt macht, gibt es einen Laufzeitfehler, weil
du nämlich die Methode eines Objektes aufrufst, die gar nicht
existiert, sprich null ist.
Hallo allerseits!
Nicht, dass ich hier kleinlich sein will. Ich weiß ja was gemeint ist, aber in solchen Foren sollte man doch etwas genauer auf die Sprache achten, da hier sicherlich viele Newbies die Beiträge lesen. Und für die ist sicher eine etwas ausfühlichere Antwort besonders hilfreich.
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.
iss mir z.B. zu Schwammig, man weiß jetzt zwat irgendwie, daß das so ist, aber warum ist das so???
int z.B. ist ein primitiver Datentyp. Mit dem Code
int a=5;
wird ein Speicherbereich angelegt in dem ein int Platz hat und mit dem Wert 5 belegt. Überall, wo im Code jetzt a verwendet wird heißt das "nimm den Inhalt aus diesem Speicherbereich der mit a markiert ist". Aus dem Code
if( a==3 ) ... wird also zur Laufzeit ein Vergleich zwischen dem aktuellen Inhalt von a und 3.
Alle Variablen, die als Typ eine Klasse haben werden als Referenzvariable bezeichnet. Auch hier muß ein Speicherbereich vorgesehen werden, der ein Objekt dieses Typs aufnehmen kann. Allerdings wird in der Variablen selbst nur ein Zeiger auf diesen Bereich gespeichert. Hat man zwei Objekte o1 und o2, dann wird auch hier bei:
if( o1==o2 ) ... der Inhalt von o1 und o2 miteinander verglichen. Dabei handelt es sich aber jetzt um die Zeiger. Das heißt, dieser Vergleich ist dann true, wenn beide Referenzvariablen auf das gleiche Objekt zeigen. Auch das kann in einem Programm eine sinnvolle Operation sein (soviel zu "immer über equals").
Wenn man überprüfen will, ob der Inhalt von Objekten übereinstimmt, dann ist die Methode equals zu benutzen. Aber Achtung! bei eigenen Objekten ist es ratsam diese Methode entsprechend zu überschreiben.
Gruß
Benky
Moin,
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.
iss mir z.B. zu Schwammig, man weiß jetzt zwat irgendwie, daß
das so ist, aber warum ist das so???
Das ist so, weil Sun es unterlassen hat, dem Token '==' einen entsprechenden Sinn zu geben. Bei C++ ist das auch bei Objekten kein Problem.
Deine Erklärung ist also als Hintergrund interessant, aber falsch aufgehängt.
Thorsten
Hi Thorsten
Das ist so, weil Sun es unterlassen hat, dem Token '==' einen
entsprechenden Sinn zu geben. Bei C++ ist das auch bei
Objekten kein Problem.
Falsch! Der Sinn von a==b ist ganz klar definiert: Vergleiche den Inhalt von Variable a mit dem Inhalt mit Variable b!
Wenn ich mich recht entsinne ist es bei C++ zunächst genauso. D.H. es werden lediglich die Referenzen miteinander verglichen. Man kann allerdings bei C++ die Operatoren überladen (was bei Strings bereits der Fall ist) und damit Objekte vom Inhalt her vergleichen. Aber man beachte: Auf einmal hat das == bei einer Variablen eine völlig andere Bedeutung, als bei einer anderen:
- wenn nicht überladen, dann Vergleich des Variableninhalts
- wenn überladen, dann Vergleich des Objektinhaltes
Und da hat Java eine klarere Linie. Wenn man den Objekt-Inhalt vergleichen will, dann muss man equals Benutzen.
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.
Wieso falsch aufgehängt??? Es ist der Hintergrund zu diesem Problem! Und nicht nur das. Der Artikel auf den ich mich ursprünglich beziehe hat zwar eine ausreichende Antwort auf das spezielle Problem geliefert, aber wenn man sich hier etwas mehr Mühe gibt und eben auch Hintergrundinfo mitliefert, dann hat das einen wesentlich größeren Nährwert! Hintergrundinfos sind eben nicht so speziell und gelten für eine ganze Reihe von Problemen.
Schau dir den Thread "Arrays in Vectoren speichern - Aber keine Referenz" an. Da hatte jemand ein Problem, das er sich mit den hier gegebenen Hintergrundinfos selbst beantworten hätte können.
Gruß
Benky
Moin,
Das ist so, weil Sun es unterlassen hat, dem Token '==' einen
entsprechenden Sinn zu geben. Bei C++ ist das auch bei
Objekten kein Problem.
Falsch!
Was genau ist da falsch?
Der Sinn von a==b ist ganz klar definiert: Vergleiche
den Inhalt von Variable a mit dem Inhalt mit Variable b!
Das bezweifle ich nicht.
Wenn ich mich recht entsinne ist es bei C++ zunächst genauso.
Jepp.
Man kann allerdings bei C++ die Operatoren überladen
Jepp
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.
Wieso falsch aufgehängt???
Er greift zu kurz, s.u.
Und da hat Java eine klarere Linie.
Im Grunde sind weder Java noch (überladenes) C++ konsequent. Ich denke halt, daß '.equals()' und der '=='-Operator semantisch völlig austauschbar sind; man hätte die Bedeutung ebensogut umdrehen können. Darum sollte man entweder Operatoren überladen können, damit der Entwickler entscheiden kann (bei Strings interessiert zB. fast nie die Referenz) oder beide Abfragen mit Methoden implementieren sollen.
Thorsten
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.
Wieso falsch aufgehängt???
Er greift zu kurz, s.u.
1. Hole ich wesentlich weiter aus, als das in der Mehrheit der anderen Antworten üblich ist.
2. Soll das ganze auch keine komplette Java-Abhandlung werden
Und da hat Java eine klarere Linie.
Im Grunde sind weder Java noch (überladenes) C++ konsequent.
Ich denke halt, daß '.equals()' und der '=='-Operator
semantisch völlig austauschbar sind; man hätte die Bedeutung
ebensogut umdrehen können. Darum sollte man entweder
Operatoren überladen können, damit der Entwickler entscheiden
kann (bei Strings interessiert zB. fast nie die Referenz) oder
beide Abfragen mit Methoden implementieren sollen.
Ich finde nach wie vor, dass der == Operator an sich in Java schon konsequent ist. (== == ==, wenn du weißt, was ich meine). Es werden die Inhalte von primitiven (Prozessornahen) Variablen miteinander verglichen, frei von jeglicher Bedeutung.
Das Problem liegt vielmehr darin, daß die primitiven Variablen im Fall von Objektreferenzen an sich in der Regel uninteressant sind, da nur Pointer auf das Objekte.
Zum vergleichen von Objekten wird daher eine Semantik nötig. Und auch das ist in Java bei allen einfachen Objekten mit der equals-Methode konsequent durchgezogen. Wohlgemerkt bei EINFACHEN Objekten.
In deinem Sinne richtig glatt bügeln lässt sich das nur, wenn man komplett auf primitive Datentypen verzichtet und alles mit Objekten und entsprechenden Methoden macht. Aber wer will das schon???
Gruß
Benky
Moin,
(== == ==, wenn du weißt, was ich meine).
So etwa.
Es werden die Inhalte von primitiven (Prozessornahen)
Variablen miteinander verglichen, frei von jeglicher
Bedeutung.
Und genau das hat in einer OO-Sprache nichts zu suchen.
In deinem Sinne richtig glatt bügeln lässt sich das nur, wenn
man komplett auf primitive Datentypen verzichtet und alles mit
Objekten und entsprechenden Methoden macht. Aber wer will das
schon???
Ich. Self und Smalltalk können das.
Und auch das ist in Java bei allen einfachen Objekten mit der
equals-Methode konsequent durchgezogen. Wohlgemerkt bei
EINFACHEN Objekten.
Mit allen, denn es gibt Comparable oder wie das heißt. Was equal ist, mußt Du dann selbst festlegen.
Thorsten
Heiho! :o)
Ich. Self und Smalltalk können das.
Naja, es gibt in Java für jeden Primitive auch ein entsprechendes Objekt. Ist dir nicht geholfen, wenn du einfach mit denen arbeitest?
Oder was machen die genannten Sprachen da anders?
Grüße, Robert