Спецификация Java L (длинная)

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

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

Ответ 1

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

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

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

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

См. раздел

Ответ 2

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

ОСНОВНАЯ ПРЕИМУЩЕСТВА: Почему платформа лучше, если предложение будет принято?

грубый код, например
 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};
может быть перекодирован как
 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Джо Дарси контролирует проектную монету для Java 7, а его блог - это простой способ отслеживать эти предложения.

Ответ 3

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

Ответ 4

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

Пример:

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 как длинного типа с помощью java-компилятора.

так наконец

Long l = 2147483648L;// works fine.

Ответ 5

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

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

Ответ 6

Рассмотрим:

long l = -1 >>> 1;

против

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

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