Спецификация номера Java (длинная)

Question

Похоже, что при вводе числа в Java компилятор автоматически считывает его как целое число, поэтому при вводе (long) 6000000000 (не в диапазоне целых чисел) он будет жаловаться, что 6000000000 не является целым числом Чтобы исправить это, мне пришлось указать 6000000000L. Я только что узнал об этой спецификации.

Существуют ли другие спецификации чисел, такие как для коротких, байтовых, плавающих, двойных? Кажется, что это было бы хорошо иметь, потому что (я полагаю), если бы вы могли указать число, которое вы набираете, было бы коротким, тогда java не пришлось бы его разыгрывать - это предположение, поправьте меня, если я ошибаюсь , Обычно я бы сам искал этот вопрос, но я не знаю, как называется такая спецификация чисел.

Answer 1

Существуют специальные суффиксы для long (например, 39832L), float (например, 2.4f) и double (например, -7.832d).

Если суффикса нет и это целочисленный тип (например, 5623), предполагается, что он равен int. Если это не целочисленный тип (например, 3.14159), предполагается, что это double.

Во всех других случаях (byte, short, char) вам нужен приведение, так как нет конкретного суффикса.

Спецификация Java допускает суффиксы как в верхнем, так и в нижнем регистре, но предпочтительна версия в верхнем регистре для long с, поскольку верхний регистр L труднее спутать с цифрой 1, чем строчными l.

См. Раздел JLS 3.10 для подробностей (см. Определение IntegerTypeSuffix).

Answer 2

Я надеюсь, что вы не будете возражать против небольшой касательной, но подумал, что вам может быть интересно узнать, что кроме F (для числа с плавающей запятой), D (для значения типа double) и L (для значения типа long) 1004 * было внесено предложение добавить суффиксы для byte и short - Y и S соответственно. Это исключило бы необходимость преобразования в байты при использовании литерального синтаксиса для байтовых (или коротких) массивов. Цитирую пример из предложения:

ОСНОВНАЯ ВЫГОДА: Почему платформа лучше, если предложение будет принято?

грубый код типа

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

можно перекодировать как

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

Джо Дарси наблюдает за Project Coin для Java 7, и его блог был простым способом отследить эти предложения.

Answer 3

Это литералы, которые описаны в разделе 3.10 спецификации языка Java.

Answer 4

По умолчанию любой тип целочисленных примитивных данных (byte, short, int, long) будет обрабатываться Java-компилятором как тип int . Для byte и short , пока назначенное им значение находится в их диапазоне, проблем нет и суффикс не требуется. Если значение, присвоенное байт и short , превышает их диапазон, требуется явное приведение типа.

Ex:

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

чтобы преодолеть это выполнение приведения типа.

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

В случае длинного типа данных он может принимать целочисленное значение без каких-либо хлопот. Предположим, что мы назначаем как

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

в этом случае суффикс типа L / l не требуется. По умолчанию значение 2147483647 считается компилятором java типа int. Внутреннее приведение типов выполняется компилятором, а int автоматически переводится в тип Long.

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

Здесь мы должны поставить суффикс как L, чтобы обработать литерал 2147483648 как тип long с помощью компилятора java.

наконец-то

Long l = 2147483648L;// works fine.

Answer 5

Кажется, это было бы хорошо есть, потому что (я полагаю), если бы вы могли укажите номер, который вы вводите в короткий, то Java не придется брось это

Так как синтаксический анализ литералов происходит во время компиляции, это абсолютно не имеет отношения к производительности. Единственной причиной, по которой было бы неплохо иметь суффиксы short и byte, является то, что это приводит к более компактному коду.

Answer 6

Рассмотрим:

long l = -1 >>> 1;

против

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

Теперь вы ожидаете, что фрагменты кода будут давать то же значение переменной l. Поэтому нам нужно, чтобы выражение для int литералов было сделано как int s.