 Datentypen Literale |
|
|
Meine Frage:
Welche Datentypen haben folgende Literale?
157
15,7
0x6EF5
Meine Ideen:
Bei 157 habe ich gedacht short, da dieser ja von -32.768 ... 32.767 geht. Doch in des Lösung steht hier int. Also ich verstehe es so das es eigentlich egal ist. Ich könnte bei 157 einen short, int oder auch long verwenden. Alles bis auf byte, da dieser ja auserhalb von 157 liegt und diese Zahl nicht "bewältigen" kann. Bei flaot und double bin ich mir nicht 100%ig sicher ob die 157 ausführen können. Eigentlich JA, da man auch 157,0 schreiben könnte. Double und float brauchen einfach mehr Speicher wie ich es verstehe. Also wenn die Effizenz von Speicher aus dem Spiel lassen würde. Könnte man ja EIGENTLICH überall wo Zahlen im Spiel sind double verwenden, oder?
Bei 15,7 hatte ich gar keinen Schimmer. Ich habe mir gedacht float, da in einer anderen Aufgabe auch 15,7f dran kam. Da war es ja easy, 'f' weist ja schon auf float hin. War mir aber irgendwie schon kalr das ich deiese Aufgabe flasch haben werde. Die Musterlösung war double, aber kann es mir nicht erklären.
Bei 0x6EF5 ist mir E und F sofort ins Auge gesprungen. E und F kam mir bekannt vom 'Umrechnen von Zahlensystemen' vor. Dort war es das Hekadezimalsystem ----> also 16Bit. Und 16Bit 2er Kompliment ist short. So erklärte ich mir meine Lösung, ... aber wiederum Flasch. Die Musterlösung war int.
|
|
23.10.2017 01:48 |
|
|
Karlito 
Kaiser
Dabei seit: 11.04.2011
Beiträge: 1.461
 |
|
Hallo WeisserBitcode,
zu 157:
Guter Ansatz. Man könnte Argumentieren, dass int architekturabhängig ist und im Allgemeinen für Ganzahlen steht. Dass man einen Fließkommatypen nehmen könnte stimmt, man vermeidet aber nach möglichkeit immer Fließkommazahlen, da sich mit Fließkommazahlen immer auch Nachteile ergeben. Vor allem aber rechnet es sich in Fließkommazahlen wesentlich schlechter als mit Ganzzahlen. Übrigens ginge Byte auf, wenn man kein Vorzeichen verwendet.
zu 15,7:
Nur anhand der Zahl kann man den Datentypen streng genommen nicht ablesen. Üblich ist es hier einen Fließkommatypen zu nehmen. Ich hätte auch float gewählt, wenn präzision nicht so die Rolle spielt. Ansonsten wegen der Genauigkeit double. Möglich wäre aber auch ein Festkommatyp (decimal).
zu 0x6EF5:
Der Präfix "0x" deutet immer auf eine Hexadezimalzahl hin. Streng genommen können wir über den Typ keine Aussage machen, da der Typ von der Interpretation der Hexadezimalzahl abhängt. Mögliche Interpretationen wären zum Beispiel:
- ein Unicode-Zeichen in UTF-16 (http://www.unicode.org/cgi-bin/GetUnihan...?codepoint=6EF5)
- ein 16-bit-integer mit oder ohne Vorzeichen
- zwei Ascii-Zeichen
- eine Speicheradresse
Im Allgemeinen sehe ich es als kritisch an, zu fragen, welchen Datentyp bestimmte Literale haben. Eine bessere Frage wäre, welchen Datentypen man wählen würde oder einen Bezug auf eine bestimmte Sprache herzustelllen, so dass es im Kontext eindeutig wird, welchen Typ das Literal bekommt.
Besten Gruß,
Karlito
|
|
|
23.10.2017 10:29 |
|
|
as_string
Haudegen
Dabei seit: 06.11.2013
Beiträge: 639
Herkunft: Heidelberg
|
|
Naja, es ist halt in C (und auch C++ denke ich) schon so, dass einfach festgelegt ist, welchen Datentyp bestimmte Literale haben. Das ist int für Ganzzahlige Werte, double für Gleitkomma-Zahlen, char für ein Zeichen in einfachen Hochkommata. Unter Ganzzahlige Werte fallen auch solche, die in hexadezimaler oder auch binärer Darstellung (glaube mit 0B... oder so) geschrieben werden, also kommt auch da ein int raus. Letztlich wird eher immer ein größerer Typ verwendet. Bei der Umwandlung einer dezimal geschriebenen Gleitkommazahl in die interne binäre IEEE754-Darstellung können ja Rundungsfehler auftreten. Würde man hier gleich ein Float nehmen, den so gerundeten Wert aber einem double zuweisen, hätte man keine Möglichkeit die volle Genauigkeit auszunutzen.
Bei int ist die Umwandlung in kleinere (oder größere, wenn es die effektiv überhaupt gibt, was von der Rechnerarchitektur abhängt) Typen recht einfach, so dass das letztendlich dann bei einer Zuweisung einfach passend umgewandelt wird. Da der Wert ja konstant feststeht, ist da auch schon zur Compile-Zeit klar, ob es bei einer Umwandlung zu Datenverlust käme und es gibt entsprechende Warnungen.
Bei Gleitkommazahlen ist die Umwandlung von double auf float zwar auch möglich, aber eher aufwändig, so dass es hier sinnvoll sein kann, gleich einen float-Wert anlegen zu lassen, so dass man hier dann das f hintenanstellen kann. Ich vermute aber stark, dass ein Compiler soetwas so wie so optimieren wird beim Kompilieren.
Übrigens schreibst Du ein Komma bei der Gleitkomma-Zahl. Das wird natürlich nicht funktionieren, da muss schon ein Punkt hin!
Gruß
Marco
|
|
|
23.10.2017 10:57 |
|
|
|
|
Hey Karlito,
vielen Dank erstmal für die schnelle Antwort 
zu 157:
Mit architekturabhängig meinst du einfach die Unterscheidung zwischen Ganzzahlen und Kommazahlen oder? Also es gibt wenn man Architektur bedingt schaut, nur diese 2 Möglichkeiten. <--- also so habe ich dies verstanden
Könntest du mir mal paar Nachteile an den Kopf schmeißen, die dir gerade so auffallen...also bezüglich zu den Fließkommazahlen? Also das man damit langsamer rechnen kann ist mir irgendwie klar, da sie ja einen längeren Bitcode besitzen <--- glaube ich zumindest
Wieso sollte Byte auch funktionieren?
Byte hat doch einen Wertebereich von -128 bis 127 also nicht enthalten.
Übrigens ginge Byte auf, wenn man kein Vorzeichen verwendet. <-- Zitat von dir.
Doch deine Aussage brachte mich nochmal zum nachdenken.
Byte hat 8 Bit Maximum. Also 1+2+4+8 + 16+32+64+128 =255 maximum (nur positiv)
OK, deine Aussage macht Sinn. Abbbber wieso gibt man dann so einen Wertebereich an?
Ich probier es mal mit Minus.... also...
1+2+4+8 + 16+32+64 = 127 <---- aber halt Minus...also = -127
Somit hätten wir einen Wertebereich von -127 bis 255 oder? Warum gibt man dann nicht einfach so etwas an? Oder muss man hier noch etwas bestimmtes beachten? Also im Endeffekt war meine aller Erste Antwort short richtig, und eigentlich auch die 'bessere' Antwort als int? Liege ich da Richtig?
Zu 15,7:
Wieso kann man Datentypen anhand von einzelnen Zahlen nicht so leicht ablesen? Was müsste man hier noch beachten? Welche Faktoren gäbe es noch zu berücksichtigen?
Du hättest float genommen wenn Präzision nicht so die Rolle spielt, aber das macht es ja auch nicht in diesem Bespiel oder? Wir habe ja nur eine Nachkommastelle. Mein Gedanke liegt darin das ich double verwende wenn die Zahl in den Milliarden Bereich mit einer Nachkommastelle oder zum Beispiel 0,24568785548665585 beträgt. Aber wenn man keine Ahnung hat einfach double verwenden, dann ist man auf der sicheren Seite, wenn ich es richtig verstanden habe.
Möglich wäre aber auch ein Festkommatyp (decimal). <-- Zitat von dir
Wie meinst du das? Verstehe ich nicht. Meinst du mit int short und so? Wenn ja, wie soll das funktionieren?
Zu 0x6EF5:
Wenn ich jetzt hier nur 6EF5 schreiben würde, wäre es doch auch eine Hexadezimalzahl oder? Muss man dieses 0x immer dazuschreiben oder ist das ehr so ne Hilfestellung? Und wir programmieren am Anfang alles in Java, also darauf basierend. Abbbbbbber wieso steht in der Lösung dann int und nicht short, weil short ist ja Hexadezimal oder?
Mit freundlichen Grüßen
WeisserBitcode
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von WeisserBitcode: 23.10.2017 19:59.
|
|
|
23.10.2017 19:48 |
|
|
|
