Specyfikacja numeru L (długiego) języka Java

Wygląda na to, że po wpisaniu liczby w Javie kompilator automatycznie odczytuje ją jako liczbę całkowitą, dlatego po wpisaniu (long) 6000000000(nie w zakresie całkowitoliczbowym) będzie narzekać, że 6000000000nie jest liczbą całkowitą. Aby to poprawić, musiałem określić 6000000000L. Właśnie dowiedziałem się o tej specyfikacji.

Czy istnieją inne specyfikacje liczbowe, takie jak short, byte, float, double? Wygląda na to, że dobrze byłoby je mieć, ponieważ (zakładam), gdybyś mógł określić numer, który wpisujesz, jest krótki, to java nie musiałby go przesyłać - to założenie, popraw mnie, jeśli się mylę . Zwykle sam bym przeszukał to pytanie, ale nie wiem, jak nazywa się tego rodzaju specyfikacja liczb.

Istnieją określone przyrostki dla long(np. 39832L), float(Np. 2.4f) I double(np -7.832d.).

Jeśli nie ma sufiksu i jest to typ całkowity (np. 5623), Zakłada się, że jest to int. Jeśli nie jest typem całkowitym (np. 3.14159), Zakłada się, że jest to typ double.

We wszystkich innych przypadkach ( byte, short, char), trzeba do obsady, ponieważ nie ma przyrostek specyficzny.

Specyfikacja języka Java zezwala na sufiksy wielkich i małych liter, ale longpreferowana jest wersja pisana dużymi literami dla s, ponieważ duże litery Lsą trudniejsze do pomylenia z liczbą 1niż małe l.

Więcej szczegółowych informacji można znaleźć w sekcji 3.10 JLS (patrz definicja IntegerTypeSuffix).

Mam nadzieję, że nie będzie miał nic przeciwko niewielki stycznie, ale pomyślałem może być zainteresowany, aby wiedzieć, że oprócz F(dla pływaka), D(za podwójne), i L(na długo), wniosek został złożony , aby dodać do przyrostków bytei short- Yi Sodpowiednio . To wyeliminowałoby potrzebę rzutowania na bajty przy używaniu składni literału dla tablic bajtowych (lub krótkich). Cytując przykład z propozycji:

GŁÓWNA KORZYŚĆ: Dlaczego platforma jest lepsza, jeśli wniosek zostanie przyjęty?

brudny kod, taki jak

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

można przekodować jako

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

Joe Darcy nadzoruje Project Coin dla Java 7, a jego blog jest łatwym sposobem na śledzenie tych propozycji.

Domyślnie każdy integralny pierwotny typ danych (bajt, krótki, int, długi) będzie traktowany jako typ int przez kompilator java. Dla bajt i zwarcia , o ile przypisana im wartość mieści się w ich zakresie, nie ma problemu i nie jest wymagany przyrostek. Jeśli wartość przypisana do bajtu i skrótu przekracza ich zakres, wymagane jest rzutowanie typu jawnego.

Dawny:

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

aby przezwyciężyć rzucanie tego typu performansu.

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

W przypadku długich typów danych może bez problemu przyjąć wartość całkowitą. Załóżmy, że przypiszemy coś podobnego

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

w tym przypadku nie jest wymagany przyrostek, taki jak L / l. Domyślnie wartość 2147483647 jest uważana przez kompilator java za typ int. Rzutowanie typu wewnętrznego jest wykonywane przez kompilator, a int jest automatycznie promowany do typu Long.

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

Tutaj musimy umieścić przyrostek jako L, aby traktować literał 2147483648 jako długi typ przez kompilator java.

więc w końcu

Long l = 2147483648L;// works fine.

Są to literały i zostały opisane w sekcji 3.10 specyfikacji języka Java.

Wygląda na to, że dobrze byłoby je mieć, ponieważ (zakładam), gdybyś mógł określić numer, który wpisujesz jest krótki, to java nie musiałby go przesyłać

Ponieważ parsowanie literałów odbywa się w czasie kompilacji, nie ma to absolutnie żadnego znaczenia w odniesieniu do wydajności. Jedynym powodem, dla którego posiadanie shorti byteprzyrostków byłoby fajne jest to, że prowadzi to do bardziej zwartego kodu.

Aby zrozumieć, dlaczego konieczne jest rozróżnienie między literami inta longliterałami, rozważ:

long l = -1 >>> 1;

przeciw

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

Jak można się słusznie spodziewać, oba fragmenty kodu nadają zmiennej tę samą wartość l. Nie będąc w stanie rozróżniać inti longdosłownie, jaka jest interpretacja -1 >>> 1?

-1L >>> 1 // ?

lub

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

Więc nawet jeśli liczba należy do wspólnego zakresu, musimy określić typ. Gdyby wartość domyślna zmieniła się wraz z wielkością literału, nastąpiłaby dziwna zmiana w interpretacji wyrażeń tylko po zmianie cyfr.

To nie wystąpić byte, shorta charponieważ są one zawsze promowane przed wykonaniem operacji arytmetycznych i bitowe. Prawdopodobnie powinny to być sufiksy typu całkowitego do użycia, powiedzmy, w wyrażeniach inicjujących tablice, ale tak nie jest. floatużywa przyrostka fi double d. Inne literały mają jednoznaczne typy, przy czym istnieje specjalny typ dla null.