Dlaczego int i = 1024 * 1024 * 1024 * 1024 kompiluje się bez błędu?

Limit intwynosi od -2147483648 do 2147483647.

Jeśli wprowadzę

int i = 2147483648;

wtedy Eclipse wyświetli czerwone podkreślenie pod „2147483648”.

Ale jeśli to zrobię:

int i = 1024 * 1024 * 1024 * 1024;

będzie się dobrze skompilować.

public class Test {
    public static void main(String[] args) {        

        int i = 2147483648;                   // error
        int j = 1024 * 1024 * 1024 * 1024;    // no error

    }
}

Może to podstawowe pytanie w Javie, ale nie mam pojęcia, dlaczego drugi wariant nie powoduje błędów.

Nie ma nic złego w tym stwierdzeniu; po prostu mnożysz 4 liczby i przypisujesz je do liczby int, po prostu zdarza się, że jest przepełnienie. Różni się to od przypisywania pojedynczego literału , który byłby sprawdzany w czasie kompilacji.

To literał poza zakresem powoduje błąd, a nie przypisanie :

System.out.println(2147483648);        // error
System.out.println(2147483647 + 1);    // no error

Z drugiej strony longliterał skompilowałby się dobrze:

System.out.println(2147483648L);       // no error

Zwróć uwagę, że w rzeczywistości wynik jest nadal obliczany w czasie kompilacji, ponieważ 1024 * 1024 * 1024 * 1024jest wyrażeniem stałym :

int i = 1024 * 1024 * 1024 * 1024;

staje się:

   0: iconst_0      
   1: istore_1      

Zwróć uwagę, że wynik ( 0) jest po prostu ładowany i zapisywany i nie ma miejsca żadne mnożenie.

Od JLS §3.10.1 (dzięki @ChrisK za poruszenie tego w komentarzach):

Jest to błąd czasu kompilacji, jeśli literał dziesiętny typu intjest większy niż 2147483648(2 ³¹ ) lub jeśli literał dziesiętny 2147483648występuje w dowolnym miejscu innym niż operand jednoargumentowego operatora minus ( §15.15.4 ).

1024 * 1024 * 1024 * 1024i 2147483648nie mają tej samej wartości w Javie.

W rzeczywistości 2147483648 NIE JEST NAWET WARTOŚCIĄ (chociaż 2147483648Ljest) w Javie. Kompilator dosłownie nie wie, co to jest ani jak go używać. Więc jęczy.

1024jest prawidłową liczbą int w Javie, a poprawna intpomnożona przez inną poprawną intjest zawsze poprawna int. Nawet jeśli nie jest to ta sama wartość, której można by się intuicyjnie spodziewać, ponieważ obliczenia będą przepełnione.

Przykład

Rozważmy następujący przykład kodu:

public static void main(String[] args) {
    int a = 1024;
    int b = a * a * a * a;
}

Czy spodziewałbyś się, że spowoduje to błąd kompilacji? Teraz robi się trochę bardziej ślisko.
A co jeśli umieścimy pętlę z 3 iteracjami i pomnożymy w pętli?

Kompilator może optymalizować, ale nie może zmieniać zachowania programu w tym czasie.

Kilka informacji o tym, jak faktycznie załatwiamy tę sprawę:

W Javie i wielu innych językach liczby całkowite będą składały się ze stałej liczby bitów. Obliczenia, które nie mieszczą się w podanej liczbie bitów, zostaną przepełnione ; Obliczenie jest wykonywane w zasadzie Modulus 2 ^ 32, Jawa, po czym wartość jest przekształcany z powrotem do podpisanego całkowitej.

Inne języki lub interfejsy API używają dynamicznej liczby bitów ( BigIntegerw Javie), zgłaszają wyjątek lub ustawiają wartość na magiczną wartość, taką jak not-a-number.

Nie mam pojęcia, dlaczego drugi wariant nie powoduje błędów.

Proponowane przez Ciebie zachowanie - to znaczy generowanie komunikatu diagnostycznego, gdy obliczenia generują wartość większą niż największa wartość, która może być przechowywana jako liczba całkowita - to cecha . Aby móc korzystać z dowolnej funkcji, należy ją przemyśleć, uznać za dobry pomysł, zaprojektować, określić, zaimplementować, przetestować, udokumentować i dostarczyć użytkownikom.

W przypadku Javy co najmniej jedna z rzeczy na tej liście się nie wydarzyła i dlatego nie masz tej funkcji. Nie wiem który; musiałbyś zapytać projektanta Java.

W przypadku C # wszystkie te rzeczy się wydarzyły - około czternaście lat temu - i dlatego odpowiedni program w C # wygenerował błąd od czasu C # 1.0.

Oprócz odpowiedzi arshajii chcę pokazać jeszcze jedną rzecz:

To nie przypisanie powoduje błąd, ale po prostu użycie literału . Kiedy próbujesz

long i = 2147483648;

zauważysz, że powoduje to również błąd kompilacji, ponieważ prawa strona nadal jest intliterą -literal i poza zakresem.

Zatem operacje z int-wartościami (i to w tym przypisania) mogą przepełniać się bez błędu kompilacji (i bez błędu czasu wykonania), ale kompilator po prostu nie może obsłużyć tych zbyt dużych literałów.

O: Ponieważ to nie jest błąd.

Tło: mnożenie 1024 * 1024 * 1024 * 1024doprowadzi do przepełnienia. Przepełnienie jest bardzo często błędem. Różne języki programowania powodują różne zachowania, gdy występują przepełnienia. Na przykład C i C ++ nazywają to „niezdefiniowanym zachowaniem” dla liczb całkowitych ze znakiem, a zachowanie jest zdefiniowane jako liczby całkowite bez znaku (weź wynik matematyczny, dodaj, UINT_MAX + 1o ile wynik jest ujemny, odejmij, UINT_MAX + 1jeśli wynik jest większy niż UINT_MAX).

W przypadku Javy, jeśli wynik operacji z intwartościami nie mieści się w dozwolonym zakresie, koncepcyjnie Java dodaje lub odejmuje 2 ^ 32, aż wynik znajdzie się w dozwolonym zakresie. Więc oświadczenie jest całkowicie legalne i nie jest błędne. Po prostu nie daje rezultatów, na jakie liczyłeś.

Z pewnością możesz się spierać, czy to zachowanie jest pomocne i czy kompilator powinien dać ci ostrzeżenie. Osobiście powiedziałbym, że ostrzeżenie byłoby bardzo przydatne, ale błąd byłby nieprawidłowy, ponieważ jest to legalna Java.