Ustawianie Java Short Value

114

Piszę mały kod w J2ME. Mam klasę z metodą setTableId(Short tableId). Teraz, kiedy próbuję pisać setTableId(100), daje to błąd czasu kompilacji. Jak ustawić wartość short bez deklarowania innej zmiennej short?

Przy ustawianiu Longwartości mogę używać setLongValue(100L)i działa. Co to więc Loznacza i jaki charakter ma Shortwartość?

Dzięki

java literals primitive-types

— Mubaszar
źródło

Ljest tylko przyrostkiem używanym do oznaczenia longliterału.

— missingfaktor

174

W Javie, literały liczb całkowitych są domyślnie typu int. Dla niektórych innych typów, można sufiks dosłowne ze bez uwzględniania wielkości liter pisma jak L, D, Faby określić długo, podwójne lub pacy, odpowiednio. Zauważ, że powszechną praktyką jest używanie wielkich liter dla lepszej czytelności.

Specyfikacja języka Java nie zapewnia tego samego cukru składniowego dla typów bajtowych i krótkich. Zamiast tego możesz zadeklarować to jako takie, używając jawnego rzutowania:

byte foo = (byte)0;
short bar = (short)0;

W setLongValue(100L)wywołaniu metody nie musisz koniecznie uwzględniać Lsufiksu, ponieważ w tym przypadku literał int jest automatycznie rozszerzany do long. Nazywa się to rozszerzającą prostą konwersją w specyfikacji języka Java.

— Lauri
źródło

16

Istnieją również przyrostki dla innych typów: d/ Dtworzy a doublei f/ Ftworzy zmiennoprzecinkowe!

— Joachim Sauer

6

Ponadto: literały, które pasują do rozmiaru, nie muszą być rzutowane: twoje dwa przykłady działają również bez obsady.

— Joachim Sauer

Masz rację na obu. Powinienem był być bardziej jasny, że mówię tutaj o literałach całkowitych, a nie o literałach zmiennoprzecinkowych.

— Lauri,

4

@Joachim: Nie wymaga rzucania tylko dla J5 +; J2ME niestety nadal znajduje się na J4 (poważnie okrojone J4).

— Lawrence Dol,

2

@JoachimSauer, co oznacza „pasuje do rozmiaru”? Pytam, bo po prostu musiał specjalnie odlewane 0jak (short)0obejść to possible lossy conversion from int to shortbłąd, choć 0 jest krótki.

— ryvantage

34

Nie ma czegoś takiego jak bajt lub krótki literał. Musisz rzucić na krótkie użycie(short)100

— er4z0r
źródło

9

Ogólnie rzecz biorąc, możesz po prostu rzutować zmienną na plik short.

Możesz również mieć takie problemy, które mogą być mylące. Dzieje się tak, ponieważ +operator promuje je do plikuint

Rzucanie elementów nie pomoże:

Musisz rzucić wyrażenie:

— matowe oparzenia
źródło

1

Nie zapominaj, że jest powód, dla którego short + short = int. Jeśli suma dwóch krótkich szortów jest większa niż maksymalna wartość krótka maszyny, rzutowanie jej na krótką albo da nieoczekiwane rezultaty, albo zgłosi wyjątek, jeśli jest obsługiwany przez języki.

— DGoiko

2

Przy takiej logice dodanie dwóch intów zwróciłoby długi;)

— Matt wypala

1

Szukam tego, jeśli moje sumy mogą przekroczyć Integer.MAX_VALUE. Nie bronię decyzji o zwróceniu int (co jest prawdopodobnie związane ze sposobem, w jaki HW faktycznie wylicza), mówię tylko, że ludzie powinni potwierdzić, że wynik faktycznie wypełnia krótki, zanim go tam umieścisz. Napotkałem więcej błędów ograniczających krótką pojemność niż ograniczających również int, prawdopodobnie ze względu na rozmiar danych liczbowych. 2 małe bajty

— rezerwy

1

Ponownie przeczytałem swój komentarz i nie wyjaśniłem tego jasno. Pierwsze zdanie jest mylące i nie powinienem był tego mówić i po prostu zostawiłem resztę, wygląda na to, że są dwa powiązane zdania. Powód, dla którego short + short jest int, można przeczytać tutaj: docs.oracle.com/javase/specs/ jvms / se8 / html /… , w JVM nie ma operacji sumujących. Wartość int w Javie wynosi 32 bity, a kiedy podejmowano te decyzje, większość komputerów miała 32 bity, więc myślę, że int wyglądał na najlepszy pomysł.

— DGoiko

1

Należy również zauważyć, że, jak wyjaśniono tutaj stackoverflow.com/a/27123302/9465588 , JVM faktycznie obsłużyła co najmniej 32 bity swojej pamięci wirtualnej na pole klasy, więc deklarowanie krótkich pól w ogóle nie oszczędza pamięci. Nie wiem, czy Java to zmieniła.

— Zwykle

8

Możesz użyć setTableId((short)100). Myślę, że zostało to zmienione w Javie 5, więc literały numeryczne przypisane do bajtu lub krótkiego i mieszczącego się w zakresie celu są automatycznie przyjmowane jako typ docelowy. Jednak najnowsze maszyny JVM J2ME wywodzą się z języka Java 4.

— Lawrence Dol
źródło

PS: Witamy w świecie bólu, który utknął w średniowieczu podczas kodowania dla J2ME. Nie mogę się doczekać, aż urządzenia przenośne dogonią komputery stacjonarne z roku 2000.

— Lawrence Dol

3

Nie ma „J4” (ani „J5”. Proszę, nie róbcie ze schematu nazewnictwa / wersjonowania Javy bardziej zagmatwanego niż już jest.

— Joachim Sauer

2

@Joachim: Java 1, Java 2, Java 5, Java 6 i Java 7 są dobrze znane i tak się do nich odnoszą; nie jest trudno ekstrapolować, co oznaczałoby Java 3 i Java 4. „Jn” jest po prostu skrótem tego, co oczywiste. Przyjęcie aktualnej (i miejmy nadzieję ostatecznej) nomenklatury firmy Sun dla wszystkich wersji zmniejsza nieporozumienia.

— Lawrence Dol

2

@Joachim: Zgodnie z ostatnim słowem Sun na ten temat, wiodące „1”. Java „1.x” należy traktować tak, jakby nigdy jej nie było w odniesieniu do omawianych wersji i jest zachowywana w wersji emitowanej przez maszyny JVM tylko w celu zapewnienia zgodności. Tak więc Java 2 jest tą wersją, która była wcześniej znana jako 1.2, skąd pochodziła J2SE (zauważysz, że w tym samym czasie firma Sun zalecała nie używać J2xE, ale raczej JavaEE, JavaSE i JavaME). Wynika z tego, że 1.3 to Java 3, 1.4 to Java 4, 1.5 to Java 5, 1.6 to Java 6, a 1.7 to Java 7. Poważnie, nie jest to trudne do wyjaśnienia.

— Lawrence Dol

2

„1” został usunięty tylko w Javie 5 i nowszych. Sun zawsze odwołuje się do Java 1.0-1.4 pod tą nazwą. Jest to robione celowo, ponieważ Sun użył „Java 2” w odniesieniu do Java 1.2 do Java 1.5 / Java 5. Jest to bardzo zagmatwane, ale wymyślanie nowych nazw, których Sun nigdy nie używał, nie ułatwia tego.

— Joachim Sauer