Nieco rozszerzam dostarczone odpowiedzi (ponieważ jak dotąd koncentrują się na swojej „własnej” / sztucznej terminologii, koncentrując się na programowaniu określonego języka zamiast zajmować się szerszym obrazem za kulisami tworzenia języków programowania , tj. Kiedy rzeczy różnica między bezpieczeństwem typu a pamięcią):
int nie jest wartością logiczną
Rozważać
boolean bar = true;
System.out.printf("Bar is %b\n", bar);
System.out.printf("Bar is %d\n", (bar)?1:0);
int baz = 1;
System.out.printf("Baz is %d\n", baz);
System.out.printf("Baz is %b\n", baz);
z wyjściem
Bar is true
Bar is 1
Baz is 1
Baz is true
Kod Java w 3. linii (bar)?1:0pokazuje, że bar ( boolean ) nie może być niejawnie przekonwertowany (rzutowany) na int . Podnoszę to, aby nie zilustrować szczegółów implementacji JVM, ale wskazać, że biorąc pod uwagę względy niskiego poziomu (jako rozmiar pamięci), należy wybierać wartości nad bezpieczeństwem typu. Zwłaszcza jeśli tego typu bezpieczeństwo nie jest w pełni / w pełni stosowane, jak w typach boolowskich, w których kontrole są przeprowadzane w formie
jeśli wartość \ w {0,1}, to rzutuj na typ boolowski, w przeciwnym razie wyrzuć wyjątek.
Wszystko po to, aby stwierdzić, że {0,1} <{-2 ^ 31, .., 2 ^ 31 -1}. Wydaje się, że to przesada, prawda? Bezpieczeństwo typów jest naprawdę ważne w typach zdefiniowanych przez użytkownika, a nie w niejawnym rzutowaniu prymitywów (chociaż ostatnie są uwzględnione w pierwszym).
Bajty nie są typami ani bitami
Zauważ, że w pamięci twoja zmienna z zakresu {0,1} nadal będzie zajmować co najmniej bajt lub słowo (xbity w zależności od wielkości rejestru), chyba że specjalnie się o to zatroszczysz (np. Ładnie zapakowany w pamięć - 8 „boolean” bitów na 1 bajt - tam iz powrotem).
Preferując bezpieczeństwo typu (jak wstawianie / zawijanie wartości do pudełka określonego typu) niż pakowanie dodatkowej wartości (np. Przy użyciu przesunięcia bitów lub arytmetyki), efektywnie wybiera się pisanie mniejszego kodu niż uzyskanie większej pamięci. (Z drugiej strony zawsze można zdefiniować niestandardowy typ użytkownika, który ułatwi całą konwersję nie wartą wartości logicznej).
słowo kluczowe a typ
Wreszcie, twoje pytanie dotyczy porównania słowa kluczowego z typem . Uważam, że ważne jest wyjaśnienie, dlaczego lub w jaki sposób uzyskasz skuteczność, używając / preferując słowa kluczowe („oznaczone” jako prymitywne ) nad typami (zwykłe złożone klasy definiowane przez użytkownika za pomocą innej klasy słów kluczowych ) lub innymi słowy
boolean foo = true;
vs.
Boolean foo = true;
Pierwszej „rzeczy” (typu) nie można rozszerzyć (podklasować) i nie bez powodu. Skutecznie terminologię Java prymitywnych i zawijających klas można po prostu przetłumaczyć na wartość wbudowaną (LITERAL lub stałą, która jest bezpośrednio zastępowana przez kompilator, ilekroć możliwe jest wnioskowanie o podstawieniu lub, jeśli nie, - powrót do zawijania wartości).
Optymalizację osiąga się dzięki trywialnym:
„Mniej operacji rzutowania w czasie wykonywania => większa prędkość.”
Dlatego po dokonaniu faktycznego wnioskowania typu może (nadal) skończyć się wystąpieniem instancji klasy zawijania ze wszystkimi informacjami o typie, jeśli to konieczne (lub konwersją / rzutowaniem na takie).
Tak więc różnica między wartością logiczną a logiczną jest dokładnie w kompilacji i środowisku wykonawczym (nieco daleko, ale prawie jak instancja vs. getClass () ).
Wreszcie, autoboksowanie jest wolniejsze niż prymitywy
Zauważ, że Java może wykonywać autoboxing to po prostu „cukier składniowy”. Nic nie przyspiesza, pozwala tylko napisać mniej kodu. Otóż to. Nadal wykonuje się rzutowanie i zawijanie do kontenera informacji o typie. Ze względu na wydajność wybierz arytmetykę, która zawsze pominie dodatkowe czynności porządkowe podczas tworzenia instancji klasy z informacjami o typie w celu wdrożenia bezpieczeństwa typu. Brak bezpieczeństwa typu to cena, którą płacisz za uzyskanie wydajności. W przypadku kodu z wyrażeniami o wartości logicznej bezpieczeństwo typu (gdy piszesz mniej, a tym samym niejawny kod) ma kluczowe znaczenie, np. W przypadku kontroli przepływu „jeśli-to-inaczej”.