OOP Methoden überladen, wo liegt das Problem?

[knowledge]

Hi,

beim Kompilieren kommt ne Fehlermeldung wenn ich später nen Aufruf wie

double result = v(3,4,'z');

mache. Sie lautet: "Reference to v is ambiguous, both method...match"

Kern der Aussage, soweit ich das verstehe. Es "passen" beide Methoden. Die Signaturen sind doch aber unterschiedlich. Warum geht das überladen so nicht? Im ersten fall ist meine Signatur: v(int,int,int). Im zweiten: v(double,double,char). Insbesondere der letzte Parameter, das char, ist ja wohl deutlich vom int zu unterscheiden. Bei dem anderen geh ich mal von aus das die Parameter von int in double konvertiert werden könnten.

Wo liegt also der Fehler?

 public static int v(int r, int h, int k) {
        return r+h+k;
 }     
    
 public static double v(double r, double h, char typ) {
        return r+h+k;
 }

 

[maki]

Ein char ist ein int bzw. sehr nahe dran 😉

 

[agentone]

char ist nichts anderes als ein Zahlentyp. Das heißt, du kannst

int a=(int)'c';

kompilieren.

 

[knowledge]

Ja, aber die doubles matchen ja nicht. Kann mir also mal jemand genau erklären wieso die methoden als gleich betrachtet werden?

 

[agentone]

Ist dir vielleicht schon aufgefallen, dass sich sowohl

int r=3;
int h=4;
int k='z';

als auch

double r=3;
double h=4;
char typ='z';

kompilieren lassen?

 

[nroz]

Ja, aber die doubles matchen ja nicht. Kann mir also mal jemand genau erklären wieso die methoden als gleich betrachtet werden?

Stell die folgende Frage:
Welcher Parameter hat höhere Priorität beim widening?
Das kann und darf die JVM nicht entscheiden also gibt es den ambigious Fehler.

 

[nroz]

3->int, 4->int, 'z'->narrowing zu short->widening zu int

oder

3->int->widening zu double, 4->int -> widening zu double, 'z'->short/char

/e angepasst mit Aussage aus dem Folgepost. ;-)

 

[fastjack]

char -> short ist kein widening, sondern narrowing, da char 16bit, short zwar ebenfalls 16bit aber zweier Komplement. Du must casten und verlierst möglicherweise etwas.

 

[knowledge]

Sehe ich es richtig das widening: typ in anderen "genauerer" typ umwandeln. wie int zu double. shortening ist umgedreht. also typgenauigkeit bzw. wertebereich eingschränken, z.B. double zu int?

Warum ein char als int dargestellt werden kann ist mir aber noch unklar.

Aber der compiler weiß halt nicht ob er die übergeben parameter "erweitern" soll zu double oder halt als int interpretieren soll, richtig?

 

[nroz]

Die JVM würde später Probleme haben zu entscheiden, welcher Methodenaufruf geschehen soll, weil in beiden Fällen aus deinem Beispiel, der Datentyp erweitert (widening) werden muss.
Wenn die Datentypen exakt für den Aufruf passen, hat der Compiler auch keine Probleme.

shortening gibt es nicht, dies geht nur durch explizites casten mit möglichem Verlust von Daten.

 

[fastjack]

Warum ein char als int dargestellt werden kann ist mir aber noch unklar.

Das ist eine Konvention in Java und liegt daran: Char ist 16bit lang, unsigned, also 0 bis 65535. Byte kann den char nicht fassen (weil 8bit signed), short auch nicht (16bit aber signed). Bleibt als kleinster Datentyp nur noch int übrig (32bit, signed). Jeder char ist ein einzelnes 16bit Unicode-Zeichen '\u0000' bis '\uffff', das intern als Zahl dargestellt wird (int).

 

[fastjack]

Hier

http://www.ifi.uzh.ch/groups/richter/Classes/SAS_SS00/SysArc4.pdf

und hier

Primitive Data Types (The Java™ Tutorials > Learning the Java Language > Language Basics)
Conversions and Promotions

findest Du noch mehr Infos zum Thema.

 

[Gastredner]

Ersetze die 3 und durch die vier durch 3.0 und 4.0, dann meckert er nicht mehr.
Grundsätzlich gilt: Zahlenliterale ohne Dezimalpunkt werden als Integer gedeutet, solche mit Dezimalpunkt als Doubles.

 

[knowledge]

die links werd ich mir anschaun. wenn ein char aber ein int ist, wieso dann eigentlich die unterscheidung char/int?

 

[Wortraum]

die links werd ich mir anschaun. wenn ein char aber ein int ist, wieso dann eigentlich die unterscheidung char/int?

Ein char ist kein int; char ist 16 Bit, int ist 32 Bit groß. Ein char wird als Unicode-Zeichen interpretiert, ein int als eine Zahl im Zweierkomplement.

Allerdings paßt ein char problemlos in ein int. Wenn Du Deine Methode aufrufst, muß irgendwo konvertiert werden, entweder die beiden ints in double oder das char in int.

Noch eine kleine Anmerkung: Irgendwo weiter oben wurde gesagt, daß ein char ein Unicode-Zeichen enthalte. Das stimmt nicht mehr, sobald beispielsweise 32-Bit-Zeichenadressen wie bei UTF-32 verwendet werden, was dann bei Java hübsche Probleme bereiten kann.

 

[knowledge]

Hallo,

ich hab es so verstanden. Intern ist ja sowieso jeder Datentyp einfach nur ein Bitmuster. Was ich davor schreibe int, double oder char sagt mir ja quasi nur, wie ich das Bitmuster zu interpretieren habe.

Ich find es nur blöd das ein char (intern ein Bitmuster von einer Länge mit 2 Byte) nun automatisch in ein int umgewandelt werden kann (widening conversion). Denn Sinn und Zweck ist es ja Zeichen darzustellen und nicht diese Zeichen in eine Zahl umzuwandeln.

Ich hab zwar verstanden das halt diese automatische Konvertierung möglich ist, aber der Sinn wieso ist mir noch nicht erschlossen.

 

[Wortraum]

Warum sollte man es verbieten? Wie will man Zeichen als Indizes in Reihungen verwenden, wie als Zählvariable?

 

[Landei]

Auf der Festplatte befinden sich Bits, und die müssen halt je nach dem entweder als Zeichen oder als Zahlen "gedeutet" werden, insofern ist es schon sinnvoll, dass man beides ineinander umwandeln kann. Ein InputStreamReader hat z.B. eine read()-Methode, die ein int liefert - egal ab es gerade DLLs oder Shakespeares gesammelte Werke liest, aber diesen int kannst du eben ganz leicht in einen char umwandeln (nicht dass ich einen InputStreamReader für Shakespeares gesammelte Werke empfehlen würde, da gibt es bessere Varianten wie BufferedReader oder ClassicalLiteratureReader).

 

[fastjack]

Das char ein 32bit Zeichen halten könnte ist interessant. Bisher habe ich nur gehört, das man im JSR-204 ein char32 einführen wollte, der das kann, das kam aber nicht so, stattdessen konnte der String Teile wie \U20000 halten. Diese Zeichen sollten aber auch in zwei chars gespeichert werden.
So ist mein Stand zu Java 6, bei 7 weis ich nicht.

        char c0 = '\u4444';
        char c1 = '\u20000'; // geht nicht
        char32 c2 = '\u20000'; // gibs nicht
        String c3 = "\u20000";
        System.out.println("length" + c3.length()); // = 2

Welch Ironie: geht nicht --> gibs nicht :applaus:

 

[agentone]

UTF-32

Waß issen das fürne Scheissse? 🙂))

2 hoch 16 = 65.536
2 hoch 32 = 4.294.967.296

Das heißt UTF-16 kann ca. 65 Tausend Zeichen darstellen.
Es gibt lautWie viele Länder gibt es... | aus Forum Geowissenschaften/Erdkunde | wer-weiss-was max. 240 Länder auf dieser Welt.

2^16 / 240 = 273

Das heißt, jedes Land dieser Erde könnte 273 Schriftzeichen für sich benutzen. Davon muss man noch mal 500 Sonderzeichen und ca. 3000 chinesische Schriftzeichen abziehen, sowie 52 lateinische Buchstaben:

(2^16 - 500 - 3000 - 52) / 240 = 258

Also immernoch viel zu viele...

Hat also jemand einen triftigen Grund, sowas zu benutzen??

 

[fastjack]

Ja, die Elben und Klingonen 😉

 

[agentone]

Elben

Ja, wenn man "Herr der Ringe" Elben- und Zwergenschrift dazuzählt, wirds knapp. 😀

Klingonen

Mit denen kenn ich mich jetzt nicht so aus, 🙁 aber vermutlich haben auch nochmal so 20.000 Schriftzeichen...

 

[fastjack]

Allerdings können alle UTF-Formate aber maximal nur alle Unicode-Zeichen darstellen, nämlich 1114112. Nur der Speicherverbrauch ist anders.