Hallo Leute
Ich habe da ein Problem in Java. Ich erzeuge mit einem Algorithmus Strings. Diese Strings werden ja intern auch nur als Nullen und Einsen dargestellt. Genau wie Integers. Nun ist meine Frage, wie ich an diese interne Darstellung herankomme um so einen Integer aus diesem String zu erzeugen oder einen double oder ähnliches also eine Art interne Typumwandlung.
Danke
Stings haben 'ne Methode charAt(), damit kannst Du Dir ein einzelnes Zeichen auslesen. Und chars sind im Prinzip auch nichts anderes als Zahlen.
Nun ist meine Frage, wie ich an diese interne Darstellung herankomme
um so einen Integer aus diesem String zu erzeugen ..
im besten Fall gar nicht,
das ist ja ein Geheimnisprinzip, Sichtbarkeit und so,
in der internen Speicherung kann da alles mögliche hinzukommen,
kann bei jedem System anders aufgebaut sein usw.,
also ich weiß nix genaues dazu,
aber ich hoffe dass es so schlimm ist, so dass niemand auf deine Idee kommt ;)
falls du wirklich nur eine einfache Abbildung von den Buchstaben auf Zahlen haben willst,
dann mit charAt bestimmt, richtig, und den Rest wieder vergessen ;)
String s = "2";
int iZwei = Integer.parseInt(s);
double dZwei = Double.parseDouble(s);
…
? :)
Nicht wirklich neu und an der Frage vorbei. Aber netter Versuch.
String foo = "bar";
int i = foo.hashCode();
falls du nur irgendwie Strings auf Zahlen zuordnen willst.
danke chris
das klingt sehr gut. Nur kann man sicher sein das verschiedene String auch auf jeden Fall unterschiedliche hashcodes haben?
Nein, schon weils mehr Strings als Integer gibt. hashcode muss nicht zwingend eindeutig sein. Das Problem wirst du aber bei jeder Zuordnung haben. Ein int entspricht 32 Bit, bei Unicode sind das gerade mal 2 Zeichen (unter der Annahme, dass alle möglichen Uncode-Kombis genutzt würden). D.h. schon bei 3 Zeichen kann man in einem Integer keine eindeutige Zuordnung mehr machen. Da Strings quasi beliebig lang sind und Integer nunmal nicht, wirst du immer mögliche Doppelgänger haben. (Eine Ausnahme wäre die klasse BigInteger, dann kann man aber auch gelich bei den Strings bleiben…)
Um so einen String einmalig zu machen, braucht man doch nur den Ort, wo er gespeichert ist. Zusammen mit dem Hashcode ist das dann ziemlich einmalig im laufenden System, oder?
Um so einen String einmalig zu machen, braucht man doch nur den Ort, wo er gespeichert ist. Zusammen mit dem Hashcode ist das dann ziemlich einmalig im laufenden System, oder?
Aeh, einmalig im System? Wie wäre es da einfach mit der Identität? Spart viel Rechenarbeit [img]
http://www.fb18.de/gfx/22.gif[/img]
ich versteh sowieso garnicht worauf das ganze hinauslaufen soll…
wofür soll das denn gut sein? oder was möchte man damit machen?
(ach ja, wenn man so komische dinge tun will, dann ist java übrigens relativ ungeeignet. aber das nur am rande.)
Um so einen String einmalig zu machen, braucht man doch nur den Ort, wo er gespeichert ist. Zusammen mit dem Hashcode ist das dann ziemlich einmalig im laufenden System, oder?
Aeh, einmalig im System? Wie wäre es da einfach mit der Identität? Spart viel Rechenarbeit [img]http://www.fb18.de/gfx/22.gif[/img]
Genau, ist ja ne Eigenschaft von Objects.
Die Bitrepräsentation eines Strings ist doch z.B. abhängig vom Speicherort. Das ist also wahrscheinlich oft eine andere Bitfolge beim gleichen String. Was willst Du damit denn bauen?
ich versteh sowieso garnicht worauf das ganze hinauslaufen soll…
wofür soll das denn gut sein? oder was möchte man damit machen?
(ach ja, wenn man so komische dinge tun will, dann ist java übrigens relativ ungeeignet. aber das nur am rande.)
Heisst ja nicht, dass das nicht machbar ist. Wenn man ambitioniert genug ist, stehen einem in Java so viele Wege offen wie in jeder anderen Programmiersprache. Nicht, dass das immer realistischen Aufwand bedeuten würde…
Um nochmal zu "eindeutigen int" zurückzukommen:
Wenn du das brauchst kannst du chars auf int typecasten um den ASCII-Code zu bekommen.
String foo = "string";
int j;
for (int i = 0; i < foo.length(); i++)
{
j += (int) foo.charAt(i);
}
bei jeder Programmausführung ein anderer Speicherplatz für den gleichen String
-> anderer Hashwert
bei jeder Programmausführung ein anderer Speicherplatz für den gleichen String
-> anderer Hashwert
Der hashcode eines Strings berechnet sich doch nicht aus dem Speicherplatz, oder hab ich jetzt irgendwas nicht verstanden [img]
http://www.fb18.de/gfx/7.gif[/img]
Wie kann ich eigentlich Object.hashCode mit einem String aufrufen?
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class HashTest {
public static void main(String[] args) throws IllegalArgumentException,
IllegalAccessException, InvocationTargetException,
SecurityException, NoSuchMethodException {
final String s1 = new String("hello, world");
final String s2 = new String("hello, world");
final Class[] noParameters = {};
final Object[] noArguments = {};
Method objHashCode = Object.class.getMethod("hashCode", noParameters);
System.out.println("" + s1.hashCode() + " " + s2.hashCode());
System.out.println(((Object) s1).hashCode());
System.out.println("" + objHashCode.invoke(s1, noArguments));
}
}
Das ergit immer das gleiche.
Wie kann ich eigentlich Object.hashCode mit einem String aufrufen?
Das geht nicht. Wäre ja auch eine Katastrophe [img]
http://www.fb18.de/gfx/8.gif[/img]
Wie kann ich eigentlich Object.hashCode mit einem String aufrufen?
Das geht nicht. Wäre ja auch eine Katastrophe [img]http://www.fb18.de/gfx/8.gif[/img]
Warum? Bei Strings sollte das doch ok sein. Und ich habs zwar nicht getestet aber das sieht so aus, als wenn low_level das "wie" gepostet hat
Wie kann ich eigentlich Object.hashCode mit einem String aufrufen?
Das geht nicht. Wäre ja auch eine Katastrophe [img]http://www.fb18.de/gfx/8.gif[/img]
Warum?
Weil das mein Bild der Polymorphie und Vererbung zerschmettern würde [img]
http://www.fb18.de/gfx/18.gif[/img]
Bei Strings sollte das doch ok sein.
Wieso jetzt gerade bei Strings? [img]
http://www.fb18.de/gfx/16.gif[/img]
Und ich habs zwar nicht getestet aber das sieht so aus, als wenn low_level das "wie" gepostet hat
Und wieso sagt er dann, dass überall das selbe herauskommt? [img]
http://www.fb18.de/gfx/3.gif[/img]
Smileys sind schon toll [img]
http://www.fb18.de/gfx/23.gif[/img]
Wie kann ich eigentlich Object.hashCode mit einem String aufrufen?
Das geht nicht. Wäre ja auch eine Katastrophe [img]http://www.fb18.de/gfx/8.gif[/img]
Warum?
Weil das mein Bild der Polymorphie und Vererbung zerschmettern würde [img]http://www.fb18.de/gfx/18.gif[/img]
*G* es passiert ja mit übermenschlichem Aufwand…
Bei Strings sollte das doch ok sein.
Wieso jetzt gerade bei Strings? [img]http://www.fb18.de/gfx/16.gif[/img]
Wenn Object z.B. die Adrsese nimmt ist das bei Strings egal, weil gleiche Strings auf gleichen Adressen landen. Bei anderen Objekten kann das anders sein und damit ungültig, weil bei per equals gelichen Dingen afair derselbe Hashcode rauskommen muss
Und ich habs zwar nicht getestet aber das sieht so aus, als wenn low_level das "wie" gepostet hat
Und wieso sagt er dann, dass überall das selbe herauskommt? [img]http://www.fb18.de/gfx/3.gif[/img]
Weil Tri ab und zu zu blöd ist, zuende zu lesen [img]
http://www.fb18.de/gfx/24.gif[/img]
[…]weil bei per equals gelichen Dingen afair derselbe Hashcode rauskommen muss
Nicht muß, nur sollte.
Doch, muss! Sonst funktionieren Datenstrukturen wie etwa Hashsets nicht mehr korrekt!
"Note that it is generally necessary to override the hashCode method whenever this method [equals] is overridden, so as to maintain the general contract for the hashCode method, which states that
equal objects must have equal hash codes."
Quelle:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)
public int hashCode() {
return 0;
}
ist durchaus gültig.
Ja, da kommt ja auch der gleiche Hashcode raus, wenn zwei Objekte equal sind… [img]
http://www.fb18.de/gfx/5.gif[/img]
Bei Strings sollte das doch ok sein.
Wieso jetzt gerade bei Strings? [img]http://www.fb18.de/gfx/16.gif[/img]
Wenn Object z.B. die Adrsese nimmt ist das bei Strings egal, weil gleiche Strings auf gleichen Adressen landen.
Noe:
String a = new String("Triphoenix");
String b = new String("Triphoenix");
System.out.println("equals? " + a.equals(b) + "\nidentisch? " + (a == b));
da wird ziemlich sicher (true, false) bei rauskommen.
[gleichheit von Strings]
Interessant, denn so wie ich hörte ist der ganze Kram mit immutable-Strins doch erfunden worden um genau so Performance zu sparen…abe rich habe da auch gerade (schonwieder *seufz*) nen Denkfehler drin…die Objektreferenzen werden verschieden liegen, der String selbst nur einmal vorhanden sein…ich lass es heute mitm Nachdenken [img]
http://www.fb18.de/gfx/22.gif[/img]
die Objektreferenzen werden verschieden liegen, der String selbst nur einmal vorhanden sein…ich lass es heute mitm Nachdenken [img]http://www.fb18.de/gfx/22.gif[/img]
Ich bin nicht ganz sicher ob ich Dich verstehe. Meinst Du, es existieren zwei String Objekte, aber nur ein Char Array, welches von beiden verwendet wird? Das kann sein, weiss ich aber nicht. Sowas kann Java sicher noch zur Kompilierzeit optimieren, aber wie sieht es aus, wenn Du per Swing zwei Strings eingeben sollst und da zweimal das gleiche eingibst?
Hab eben noch folgendes gefunden
public String(String original)Initializes a newly created String object so that it represents the same sequence of characters as the argument; in other words, the newly created string is a copy of the argument string. Unless an explicit copy of original is needed, use of this constructor is unnecessary since Strings are immutable.
Ich weiss aber immer noch nicht, ob das Array nun kopiert wird oder nicht [img]
http://www.fb18.de/gfx/16.gif[/img]
bei jeder Programmausführung ein anderer Speicherplatz für den gleichen String
-> anderer Hashwert
Der Hashwert eines Strings und seine Bitrepräsentation sind doch vollkommen verschiedene Dinge..
Ich sprach von der Bitrepräsentation. Da sind doch sicher auch "Metainformationen" drin. Die können variieren bei zwei gleichen Buchstabenfolgen. Das meinte ich. Nicht, dass ich's wirklich WÜSSTE, aber es erscheint mir plausibel.
Ich bin nicht ganz sicher ob ich Dich verstehe. Meinst Du, es existieren zwei String Objekte, aber nur ein Char Array, welches von beiden verwendet wird?
Jap
Das kann sein, weiss ich aber nicht. Sowas kann Java sicher noch zur Kompilierzeit optimieren, aber wie sieht es aus, wenn Du per Swing zwei Strings eingeben sollst und da zweimal das gleiche eingibst?
Für den neuen wird neuer Platz genommen. Deswegen sind Dinge wie String a = "bla"; a = a + "bla"; nicht sehr schön, weil dafür ein neuer String genommen wird. immutable halt.
Hab eben noch folgendes gefunden
public String(String original)Initializes a newly created String object so that it represents the same sequence of characters as the argument; in other words, the newly created string is a copy of the argument string. Unless an explicit copy of original is needed, use of this constructor is unnecessary since Strings are immutable.
Ich weiss aber immer noch nicht, ob das Array nun kopiert wird oder nicht [img]http://www.fb18.de/gfx/16.gif[/img]
Ich schätze in diesem Fall schon, weil der Kommentar ja sagt, dass mans nur nehmen soll, wenn mans wirklich braucht um eine echte Kopie zu haben.
weil gleiche Strings auf gleichen Adressen landen.
Nein. Gleiche StrinkKONSTANTEN landen auf der gleichen Adresse. Oder glaubst Du, dass jedesmal, wenn zur Laufzeit dynamisch ein String erstellt wird, der gesamte Stringpool durchsucht wird? Dafür gibts String.intern()
[oh. Einen Teil davon hat Fred ja schon geschrieben. Naja, doppelt hält besser.]
Ich sag ja ich sollte es aufgeben [img]
http://www.fb18.de/gfx/22.gif[/img]…
weil gleiche Strings auf gleichen Adressen landen.
Nein. Gleiche StrinkKONSTANTEN landen auf der gleichen Adresse.
Ich hab's erst selbst nicht geglaubt, aber es stimmt. Zwei Stringliterale mit dem gleichen Wert sind garantiert identisch. (Quelle: Java Language specification 2.0, 3.10.5 "String Literals")
[…]weil bei per equals gelichen Dingen afair derselbe Hashcode rauskommen muss
Nicht muß, nur sollte.
Doch, muss! Sonst funktionieren Datenstrukturen wie etwa Hashsets nicht mehr korrekt!
Ok, ich hab falschrum gedacht.
Es muß bei ungleichen Objekten kein ungleicher Hashcode existieren. Andersrum aber schon.
Wobei es natürlich schöner ist wenn ungleiche Objekte verschiedene Hashcodes liefern, und das HashSet wird performanter…
Es muß bei ungleichen Objekten kein ungleicher Hashcode existieren.
Das kann man ja auch gar nicht verlangen, da Du eine sehr grosse Menge von möglichen Objekten auf 32 Bit Integer abbilden musst. Bei Strings ab 5 Zeichen Länge gibt es zwangsweise schon Kollisionen.
Andersrum aber schon.
Richtig, man kann diese Aussage auf zwei Arten darstellen:
a.equals(b) => a.hashCode() == b.hashCode()
a.hashCode() != b.hashCode() => !(a.equals(b))
Aber für diejenigen unter uns, die bei F1 aufgepasst haben, ist das natürlich trivial [img]
http://www.fb18.de/gfx/28.gif[/img]
Wobei es natürlich schöner ist wenn ungleiche Objekte verschiedene Hashcodes liefern, und das HashSet wird performanter…
Richtig, ein Ansatz a la "return 0" führt die Idee des Hashings ad absurdum.
bei jeder Programmausführung ein anderer Speicherplatz für den gleichen String
-> anderer Hashwert
Der Hashwert eines Strings und seine Bitrepräsentation sind doch vollkommen verschiedene Dinge..
Ich sprach von der Bitrepräsentation. Da sind doch sicher auch "Metainformationen" drin. Die können variieren bei zwei gleichen Buchstabenfolgen. Das meinte ich. Nicht, dass ich's wirklich WÜSSTE, aber es erscheint mir plausibel.
"Metainformationen"? Was soll das sein? Der String selber (char-Array, immer die gleiche Bitrepraesentation), die Laenge (gleiche Strings sind immer gleich lang…). Mehr kanns nicht geben… Was soll sich da unterscheiden?
Und @Fred: Wenn das unten gepostete dein Weltbild von Polymorphie ueber den Haufen wirft, scheint mir das auch ganz gut so :)
MoKrates
Mehr kanns nicht geben… Was soll sich da unterscheiden?
der String kann doch z.B. mal als Unicode oder Ascii gespeichert werden?
Soweit ich weiß gibts in Java nur Unicode.
Character information is based on the Unicode Standard, version 3.0.
(aus dem Character-Javadoc)
Unicode, der aber in UTF8 Codiert wird afair
Waere das nicht 8 Bit fuer "normale" Ansi-Zeichen? Dann AFAIK nicht. Denn "char" hat in Java AFAIR 16 Bit.
MoKrates
Waere das nicht 8 Bit fuer "normale" Ansi-Zeichen? Dann AFAIK nicht. Denn "char" hat in Java AFAIR 16 Bit.
MoKrates
Ein char muss aber nicht die
interne Darstellung aller Zeichen sein
Ich meine irgendwo in $Doku gelesen zu haben das ein String als array of chars abgebildet wird (nicht werden kann, sondern wird).
Ich meine irgendwo in $Doku gelesen zu haben das ein String als array of chars abgebildet wird (nicht werden kann, sondern wird).
Also Stringkonstanten werden wies aussieht schonmal als UTF8 gespeichert, zumindest im Classfile (elendes Dokuwühlen *G*)
Hm. Ich entschließe mich dieses Gemisch aus primitiven Typen und Objekten doof zu finden und gebe mich geschlagen. [img]
http://www.fb18.de/gfx/25.gif[/img]
