Почему Java не поддерживает неподписанный ints?

Я могу думать об одном неудачном побочном эффекте. Во встроенных базах данных Java количество идентификаторов, которые Вы можете иметь с идентификационным полем на 32 бита, 2^31, не 2^32 (~2billion, не ~4billion).

Я услышал истории, что они должны были быть включены близко к orignal выпуску Java. Дуб был предшественником Java, и в некоторых документах спецификации было упоминание о значениях usigned. К сожалению, они никогда не превращали его на язык Java. Насколько любой был в состоянии выяснить, что они просто не стали реализованными, вероятно, из-за ограничения времени.

Я думаю, что Java прекрасен, как это, добавление неподписанного усложнило бы его без большого количества усиления. Даже с упрощенной целочисленной моделью, большинство программистов Java не знает, как основные числовые типы ведут себя - просто читает книжные Трудные вопросы Java для наблюдения, какие неправильные представления Вы могли бы держать.

Что касается практического совета:

• , Если Ваши значения являются несколько произвольным размером и не вписываются int, используйте long. Если они не вписываются long использование BigInteger.

• Использование меньшие типы только для массивов, когда необходимо оставить свободное место.

• при необходимости точно 64/32/16/8 в битах используйте long / int / short / byte и прекратите волноваться о знаковом бите, за исключением подразделения, сравнения, сдвига вправо, и бросать.

См. также этот ответ о "портировании генератора случайных чисел от C до Java".

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

Этот парень говорит, потому что стандарт C определяет операции, включающие неподписанный и ints со знаком, который будут рассматривать как неподписанный. Это могло заставить отрицательные целые числа со знаком вращаться в большой неподписанный интервал, потенциально вызвав ошибки.

Как только подписано и неподписанные ints смешаны в выражении, вещи начинают становиться грязными, и Вы, вероятно будете терять информацию. Ограничение Java к ints со знаком только действительно разрешает вещи. I’m, довольный я, которого don’t должны взволновать по поводу целого бизнеса со знаком/неподписанного, хотя я иногда пропускаю 8-й бит в байте.

Читать между строк, я думаю, что логика была чем-то вроде этого:

• обычно, разработчики Java хотели упростить репертуар типов данных, доступных
• в повседневных целях, они чувствовали, что наиболее распространенная потребность была для типов данных со знаком
• для реализации определенных алгоритмов, неподписанная арифметика иногда необходима, но вид программистов, которые реализовали бы такие алгоритмы, будет также иметь знание для "работы вокруг" выполнения неподписанной арифметики с типами данных со знаком

Главным образом, я сказал бы, что это было разумное решение. Возможно, я имел бы:

• сделанный неподписанным байтом, или по крайней мере обеспечили альтернативы со знаком/неподписанные, возможно с различными именами, для этого типа данных (делающий, это подписалось, хорошо для непротиворечивости, но когда Вам когда-либо нужен байт со знаком?)
• поконченный 'короткий' (когда Вы в последний раз использовали 16-разрядную арифметику со знаком?)

однако, с небольшим количеством kludging, операциями на неподписанных значениях до 32 битов не являются tooo плохо, и большинству людей не нужны неподписанное 64-разрядное подразделение или сравнение.

В спецификации «C» есть несколько драгоценных камней, которые Java отбросила по прагматическим причинам, но которые медленно набирают обороты со стороны разработчиков (замыкания и т. Д.).

Я упоминаю первый, потому что это связано с этим обсуждением; соответствие значений указателя целочисленной арифметике без знака. И, что касается этой темы, трудность поддержания семантики без знака в мире Java со знаком.

Я бы предположил, что если бы кто-то получил альтернативное эго Денниса Ричи, чтобы посоветовать команде разработчиков Гослинга, он предложил бы дать Signed "ноль на бесконечности", чтобы все запросы смещения адресов сначала добавляли свой АЛГЕБРАИЧЕСКИЙ РАЗМЕР КОЛЬЦА, чтобы избежать отрицательного. значения.

Таким образом, любое смещение, выброшенное в массив, никогда не может генерировать SEGFAULT. Например, в инкапсулированном классе, который я называю RingArray типа double, для которого необходимо поведение без знака - в контексте «самовращающегося цикла»:

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

Приведенный выше RingArray никогда не получит «отрицательный» индекс, даже если злоумышленник попытался. Помните, что есть также много законных запросов для запроса предыдущих (отрицательных) значений индекса.

Примечание: внешний модуль% отменяет ссылки на законные запросы, тогда как внутренний модуль% маскирует явную злобу от негативов, более негативных, чем -модул. Если бы это когда-либо появилось в Java + .. + 9 || 8 + .. + spec, тогда проблема действительно превратилась бы в «программиста, который не может« самостоятельно вращать »FAULT».

Я уверен, что так называемый «дефицит» в Java unsigned int можно восполнить с помощью приведенного выше однострочного.

PS: Просто для того, чтобы дать контекст вышеприведенному ведению RingArray, вот операция-кандидат 'set', соответствующая вышеописанной операции элемента 'get':

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

В Java есть беззнаковые типы, или хотя бы один: char является беззнаковым коротким. Так что какие бы отговорки ни приводил Гослинг, на самом деле это просто его незнание, почему нет других беззнаковых типов.

Также Короткие типы: короткометражки всегда используются для мультимедиа. Причина в том, что вы можете уместить 2 образца в один 32-битный беззнаковый длинный и векторизовать множество операций. То же самое с 8-битными данными и беззнаковым байтом. Вы можете разместить 4 или 8 образцов в регистре для векторизации.