LINUX.ORG.RU

История изменений

Исправление rukez, (текущая версия) :

подобных примитивов нету, BigDecimal единственный подходящий тип, но он не имеет операторов.

BigDecimal не примитив по этому у него операторы обернуты функциями, что кстати местами полезно (например при делении)

О чем ты говоришь, есть же short.

А я не уверен что он 16 бит внутри (ниже)

Надеюсь ты это не из бредогенератора копируешь. Есть регистры ax, bx, cx, … У тебя очень странная информация… Даже интересно стало, как ты пришел к такому мнению о 16 битах.

Жвм в общем случае приводит все к инту притом системной длины под капотом т.е. short вроде как может занимать 16 бит при хранении (по крайней мере оракл так пишет) но при каждой математической операции будет развертываться в 32 бита - по этому по факту ими никто особо не пользуется ибо инт обычно шустрее
С байтом кстати я выше тоже налюбил - он тоже в 32 бита минимум развернется в большинстве случаев

Есть регистры ax

Ax и иже с ним разве до сих пор самодостаточные а не просто половинка от еах?

Исходная версия rukez, :

подобных примитивов нету, BigDecimal единственный подходящий тип, но он не имеет операторов.

BigDecimal не примитив по этому у него операторы обернуты функциями, что кстати местами полезно (например при делении)

О чем ты говоришь, есть же short.

А я не уверен что он 16 бит внутри (ниже)

Надеюсь ты это не из бредогенератора копируешь. Есть регистры ax, bx, cx, … У тебя очень странная информация… Даже интересно стало, как ты пришел к такому мнению о 16 битах.

Жвм в общем случае приводит все к инту притом системной длины под капотом т.е. short вроде как может занимать 16 бит при хранении (по крайней мере оракл так пишет) но при каждой математической операции будет развертываться в 32 бита - по этому по факту ими никто особо не пользуется ибо инт обычно шустрее
С байтом кстати я выше тоже налюбил - он тоже в 32 бита минимум развернется в большинстве случаев