Javas L-Nummer (lang) Spezifikation

Lesezeit: 8 Minuten

Javas L Nummer lang Spezifikation
jbu

Es scheint, dass der Compiler beim Eingeben einer Zahl in Java diese automatisch als Ganzzahl liest, weshalb beim Eingeben von (long) 6000000000 (nicht im Integer-Bereich) wird es sich darüber beschweren 6000000000 ist keine ganze Zahl. Um dies zu korrigieren, musste ich angeben 6000000000L. Ich habe gerade von dieser Spezifikation erfahren.

Gibt es andere Zahlenangaben wie für short, byte, float, double? Es scheint, als wären diese gut zu haben, denn (ich nehme an), wenn Sie angeben könnten, dass die Nummer, die Sie eingeben, kurz ist, müsste Java sie nicht umwandeln – das ist eine Annahme, korrigieren Sie mich, wenn ich falsch liege . Normalerweise würde ich diese Frage selbst suchen, aber ich weiß nicht, wie diese Art von Zahlenangabe überhaupt heißt.

Javas L Nummer lang Spezifikation
Simon Nickerson

Es gibt bestimmte Suffixe für long (z.B 39832L), float (z.B 2.4f) und double (z.B -7.832d).

Wenn kein Suffix vorhanden ist und es sich um einen ganzzahligen Typ handelt (z 5623), es wird angenommen, dass es sich um eine handelt int. Wenn es sich nicht um einen ganzzahligen Typ handelt (z 3.14159), es wird angenommen, dass es sich um a handelt double.

In allen anderen Fällen (byte, short, char), benötigen Sie die Besetzung, da es kein bestimmtes Suffix gibt.

Die Java-Spezifikation erlaubt sowohl Groß- als auch Kleinbuchstaben-Suffixe, aber die Großbuchstaben-Version für longs wird als Großbuchstabe bevorzugt L ist weniger leicht mit einer Zahl zu verwechseln 1 als die Kleinschreibung l.

Siehe die JLS-Abschnitt 3.10 für die blutigen Details (siehe die Definition von IntegerTypeSuffix).

  • Nachträglicher Eintrag: Das Entfernen potenzieller Mehrdeutigkeitsquellen ist immer gut, und Ich bin nicht anderer Meinung… aber ich glaube, wenn Sie sich verwirrend fühlen 1 mit l und 0 mit O (und so weiter), Ihre Priorität ist es, die Schriftart richtig einzustellen (wenn Sie können), und sich dann darum zu kümmern, dass Sie die Umschalttaste nicht verpassen.

    – davidcesarino

    2. April 12 um 17:02 Uhr

  • @SimonNickerson Ich habe eine Frage zu Suffixen … Wenn ich a deklariere lang oder ein doppelt Variable wie: long _lo = 30; und nicht 30L Bedeutet dies, dass meine Variable umgewandelt wird in schweben ? Oder im Falle von _lo = _lo + 2.77 das _lo hineingegossen wird schweben obwohl es so deklariert war lang

    – luigi7up

    19. Oktober 12 um 10:28 Uhr


  • Nein, Schwimmer sind hier nicht beteiligt. Im ersten Fall, 30 ist ein int die automatisch über eine Erweiterungskonvertierung in a konvertiert wird long. Im zweiten Fall ist Ihre Aussage rechtswidrig. Sie müssten die rechte Seite explizit zu lang werfen, z _lo = (long) (_lo + 2.77)

    – Simon Nickerson

    19. Oktober 12 um 11:49 Uhr

  • @DavidCesarino Wenn Sie die Schriftart ändern, wird die Mehrdeutigkeit für Sie behoben – in diesem bestimmten Editor, in dem Sie sie richtig eingestellt haben. Das Ändern von l zu L behebt die Mehrdeutigkeit für alle wer könnte jemals Ihren Code lesen, einschließlich Sie selbst, wenn Sie den Code in einem anderen Editor, einer anderen IDE lesen und sich die Quelle im Web ansehen (Review-Tools, Repositories usw.). IMHO ist die Priorität, die Umschalttaste nicht zu verpassen. Übrigens. welche Schriftart empfehlt ihr? Ich mag Monospace und es ist die Standardeinstellung in fast allen Editoren, CLIs usw., die ich gesehen habe, und in dieser Schriftart l und 1 (0 und O bzw.) ziemlich ähnlich sind.

    – Dingalapadum

    24. April 17 um 19:57 Uhr


  • @dingalapadum Wie gesagt, du hast Recht. Quellen der Mehrdeutigkeit zu beseitigen, ist definitiv richtig. Ich sagte nur, Sie sollten versuchen, keinen Editor zu verwenden, bei dem Sie ihn leicht verwechseln könnten. Mit anderen Worten, der alte Vorschlag, defensiv zu codieren, aber nicht davon abhängig zu sein. Was die Schriftart betrifft, sie ist sehr persönlich, aber ich verwende immer Deja Vu Sans Mono, wann immer ich kann, weil 1) sie monospaced ist; 2) es gibt keine Zweideutigkeiten zwischen den Zeichen; und 3) Ich mag seine Formen, schön und anmutig, fast wie eine gute, lesbare Sans-Serif-Schrift (andere gute Programmierschriften fühlen sich meiner Meinung nach zu “metallisch” an).

    – davidcesarino

    2. Mai 17 um 11:04 Uhr

1641904454 625 Java nicht erreichbarer Catch Block Compilerfehler
Utpal Kumar

Standardmäßig wird jeder ganzzahlige primitive Datentyp (byte, short, int, long) behandelt int Typ von Java-Compiler. Für Byte und kurz, solange der ihnen zugewiesene Wert in ihrem Bereich liegt, gibt es kein Problem und es ist kein Suffix erforderlich. Wenn Wert zugewiesen zu Byte und kurz ihren Bereich überschreitet, ist eine explizite Typumwandlung erforderlich.

Ex:

byte b = 130; // CE: range is exceeding.

um diesen Perform-Type-Casting zu überwinden.

byte b = (byte)130; //valid, but chances of losing data is there.

Im Falle eines langen Datentyps kann es problemlos den ganzzahligen Wert akzeptieren. Angenommen, wir weisen like zu

long l = 2147483647; //which is max value of int

in diesem Fall ist kein Suffix wie L/l erforderlich. Standardmäßig wird der Wert 2147483647 vom Java-Compiler als int-Typ betrachtet. Die interne Typumwandlung erfolgt durch den Compiler und int wird automatisch zum Long-Typ hochgestuft.

long l = 2147483648; //CE: value is treated as int but out of range 

Hier müssen wir das Suffix als L setzen, um das Literal 2147483648 vom Java-Compiler als langen Typ zu behandeln.

so endlich

long l = 2147483648L;// works fine.

1643140028 304 Javas L Nummer lang Spezifikation
Erickson

Ich hoffe, Sie haben nichts gegen eine leichte Tangente, dachte aber, dass es Sie vielleicht interessieren würde, das außerdem zu wissen F (für Schwimmer), D (für doppelt) und L (für lange), ein Vorschlag wurde gemacht Suffixe hinzufügen für byte und shortY und S bzw. Dies würde die Notwendigkeit beseitigen, in Bytes umzuwandeln, wenn Literal-Syntax für Byte- (oder kurze) Arrays verwendet wird. Zitat des Beispiels aus dem Vorschlag:

GROßER NUTZEN: Warum ist die Plattform besser, wenn der Vorschlag angenommen wird?

cruddy Code wie

 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};

kann umcodiert werden als

 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Joe Darcy beaufsichtigt Project Coin für Java 7 und sein Blog war eine einfache Möglichkeit, diese Vorschläge zu verfolgen.

  • das wäre schön… Ich fand immer, dass die ganzen Besetzungen wirklich nervig sind

    – jbu

    20. April 09 um 20:48 Uhr

  • Ich nehme an, das hat es nicht in Java 7 geschafft. Irgendwelche Informationen darüber, ob es in ein zukünftiges Update oder Java 8 kommen wird?

    – zerquetschen

    28. August 13 um 21:12 Uhr

  • @crush Ich habe vor ein paar Monaten versucht, mich damit zu befassen, und soweit ich das beurteilen konnte, war der Vorschlag aufgegeben worden. Wir haben _ in numerischen Literalen erhalten und die 0b Präfix für binäre Literale. Hoppla.

    – Ericsson

    28. August 13 um 22:15 Uhr

  • Diese Vorschläge werden wahrscheinlich auf Kotlin anstelle von Java implementiert, da Oracle nicht möchte, dass die Community ihnen sagt, wie sie arbeiten sollen … wir sind auf 2018 und leider immer noch nichts über diesen Vorschlag

    – Joel Bonet R

    28. März 18 um 15:17 Uhr

1643140028 592 Javas L Nummer lang Spezifikation
McDowell

Dies sind Literale und werden in beschrieben Abschnitt 3.10 der Java-Sprachspezifikation.

Es scheint, als wären diese gut zu haben, denn (ich nehme an), wenn Sie angeben könnten, dass die Nummer, die Sie eingeben, kurz ist, müsste Java sie nicht umwandeln

Da das Parsen von Literalen zur Kompilierzeit erfolgt, ist dies hinsichtlich der Performance absolut irrelevant. Der einzige Grund mit short und byte Suffixe wären schön, weil sie zu kompakterem Code führen.

Um zu verstehen, warum es notwendig ist, zwischen zu unterscheiden int und long Literale, bedenke:

long l = -1 >>> 1;

gegen

int a = -1;
long l = a >>> 1;

Nun, wie Sie zu Recht erwarten würden, geben beide Codefragmente der Variablen denselben Wert l. Ohne unterscheiden zu können int und long Literale, was ist die Interpretation von -1 >>> 1?

-1L >>> 1 // ?

oder

(int)-1 >>> 1 // ?

Auch wenn die Zahl im gemeinsamen Bereich liegt, müssen wir den Typ angeben. Wenn sich die Standardeinstellung mit der Größe des Literals ändern würde, würde es eine seltsame Änderung in der Interpretation von Ausdrücken geben, nur weil die Ziffern geändert werden.

Dies tritt z byte, short und char da sie immer hochgestuft werden, bevor arithmetische und bitweise Operationen durchgeführt werden. Sie sollten wohl Suffixe vom Typ Integer sein, die beispielsweise in Array-Initialisierungsausdrücken verwendet werden können, aber es gibt keine. float verwendet Suffix f und double d. Andere Literale haben eindeutige Typen, wobei es einen speziellen Typ für gibt null.

Java hat zwei Arten von Datentypen:

  1. Primitive Datentypen
  2. Nicht primitiver Datentyp

Bestimmte Datentypen erfordern Spezifikationen wie long, float und double.

Denken Sie beim Zuweisen eines der oben genannten Datentypen zu einer beliebigen Variablen immer daran, ….

  • Beenden Sie den Wert mit einem „d“ im Double-Datentyp.
  • Beenden Sie den Wert mit einem „L“ im langen Datentyp.
  • Beenden Sie den Wert mit einem „f“ im Float-Datentyp.

Beispiel:

lange Zahl = 15000000000L;

float mysecondnum = 5,75f;

doppelte mynumber = 19,99d;

Mehr Info:

  • Die Größe des langen Datentyps beträgt 8 Bytes.
  • Die Größe des Float-Datentyps beträgt 4 Bytes.
  • Die Größe des Double-Datentyps beträgt 8 Bytes.

Das Genauigkeitsniveau des langen Datentyps beträgt bis zu 7-8 Dezimalstellen, während der Float-Datentyp bis zu 15 Dezimalstellen beträgt.

Bearbeiten:

Zusammen mit dieser Typumwandlung kann der primitive Datentyp von einem zum anderen geändert werden.

  • Verbreiterungsguss (automatisch): kleinere Schrift auf eine größere Schriftgröße
  • Verengendes Gießen (manuell): Größerer Typ auf einen kleineren Typ

.

636400cookie-checkJavas L-Nummer (lang) Spezifikation

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy