Perché Java non supporta gli integ non firmati?

Perché Java non include il supporto per numeri interi senza segno?

Mi sembra una strana omissione, dato che consentono di scrivere codice che ha meno probabilità di produrre overflow su input inaspettatamente grandi.

Inoltre, l'uso di numeri interi senza segno può essere una forma di autocertificazione, poiché indicano che il valore che l'int non firmato doveva contenere non dovrebbe mai essere negativo.

Infine, in alcuni casi, numeri interi senza segno possono essere più efficienti per determinate operazioni, come la divisione.

Qual è il lato negativo di includere questi?

Questo è da un'intervista a Gosling e altri , sulla semplicità:

Gosling: Per me come progettista del linguaggio, che in realtà non mi considero come al giorno d'oggi, quale significato "semplice" alla fine è stato possibile aspettarmi che J. Random Developer avesse in mente le specifiche. Tale definizione afferma che, ad esempio, Java non lo è - e in effetti molti di questi linguaggi finiscono con molti casi angolari, cose che nessuno capisce davvero. Interroga qualsiasi sviluppatore C su unsigned, e molto presto scopri che quasi nessuno sviluppatore C in realtà capisce cosa succede con unsigned, che cos'è l'aritmetica senza segno. Cose del genere hanno reso C complesso. La parte linguistica di Java è, credo, piuttosto semplice. Le librerie che devi cercare.

Leggendo tra le righe, penso che la logica fosse qualcosa del genere:

• in generale, i progettisti Java volevano semplificare il repertorio dei tipi di dati disponibili
• per scopi quotidiani, ritenevano che l'esigenza più comune fosse quella di tipi di dati firmati
• per l'implementazione di determinati algoritmi, talvolta è necessaria l'aritmetica senza segno, ma il tipo di programmatori che implementerebbe tali algoritmi avrebbe anche le conoscenze per "aggirare" facendo l'aritmetica senza segno con tipi di dati firmati

Principalmente, direi che è stata una decisione ragionevole. Forse avrei:

• reso byte senza segno, o almeno hanno fornito alternative firmate / non firmate, possibilmente con nomi diversi, per questo tipo di dati (renderlo firmato è buono per coerenza, ma quando mai hai bisogno di un byte con segno?)
• eliminato con 'short' (quando hai usato l'ultima volta l'aritmetica firmata a 16 bit?)

Tuttavia, con un po 'di kludging, le operazioni su valori senza segno fino a 32 bit non sono troppo male e la maggior parte delle persone non ha bisogno di divisione o confronto a 64 bit senza segno.

Questa è una domanda più vecchia e Pat ha menzionato brevemente il personaggio, ho pensato che avrei dovuto approfondire questo aspetto per gli altri che lo guarderanno lungo la strada. Diamo un'occhiata più da vicino ai tipi primitivi Java:

byte - Numero intero con segno a 8 bit

short - Numero intero con segno a 16 bit

int - Numero intero con segno a 32 bit

long - Numero intero con segno a 64 bit

char - Carattere a 16 bit (intero senza segno)

Sebbene charnon supporti l' unsignedaritmetica, in sostanza può essere trattato come un unsignednumero intero. Dovresti ricollegare esplicitamente le operazioni aritmetiche char, ma ti fornisce un modo per specificare i unsignednumeri.

char a = 0;
char b = 6;
a += 1;
a = (char) (a * b);
a = (char) (a + b);
a = (char) (a - 16);
b = (char) (b % 3);
b = (char) (b / a);
//a = -1; // Generates complier error, must be cast to char
System.out.println(a); // Prints ? 
System.out.println((int) a); // Prints 65532
System.out.println((short) a); // Prints -4
short c = -4;
System.out.println((int) c); // Prints -4, notice the difference with char
a *= 2;
a -= 6;
a /= 3;
a %= 7;
a++;
a--;

Sì, non esiste un supporto diretto per numeri interi senza segno (ovviamente, non dovrei riportare la maggior parte delle mie operazioni in caratteri se ci fosse un supporto diretto). Tuttavia, esiste sicuramente un tipo di dati primitivo senza segno. Mi sarebbe piaciuto vedere anche un byte senza segno, ma immagino che raddoppiare il costo della memoria e invece usare char sia un'opzione praticabile.

modificare

Con JDK8 ci sono nuove API per Longe Integerche forniscono metodi di supporto durante il trattamento longe i intvalori come valori senza segno.

• compareUnsigned
• divideUnsigned
• parseUnsignedInt
• parseUnsignedLong
• remainderUnsigned
• toUnsignedLong
• toUnsignedString

Inoltre, Guava fornisce una serie di metodi di supporto per fare cose simili per i tipi interi che aiuta a colmare il divario lasciato dalla mancanza di supporto nativo per gli unsignedinteri.

Java ha tipi senza segno, o almeno uno: char è un corto senza segno. Quindi, qualunque scusa Gosling sollevi, in realtà è solo la sua ignoranza perché non ci sono altri tipi senza segno.

Anche i tipi corti: i pantaloncini vengono usati continuamente per i contenuti multimediali. Il motivo è che è possibile inserire 2 campioni in un singolo unsigned long a 32 bit e vettorializzare molte operazioni. Stessa cosa con dati a 8 bit e byte senza segno. È possibile inserire 4 o 8 campioni in un registro per la vettorializzazione.

Non appena firmati e unsigned int sono mescolati in un'espressione cose iniziano a farsi disordinato e probabilmente sarà perdere le informazioni. Limitare Java agli ints firmati chiarisce davvero le cose. Sono contento di non dovermi preoccupare dell'intera attività firmata / non firmata, anche se a volte mi manca l'ottavo bit in un byte.

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

Questo ragazzo dice perché lo standard C definisce le operazioni che coinvolgono ints non firmati e firmati da trattare come non firmati. Ciò potrebbe far sì che numeri interi con segno negativo si spostino all'interno di un int non firmato di grandi dimensioni, causando potenzialmente bug.

Penso che Java vada bene così com'è, l'aggiunta di unsigned lo complicherebbe senza molto guadagno. Anche con il modello intero semplificato, la maggior parte dei programmatori Java non sa come si comportano i tipi numerici di base: basta leggere il libro Java Puzzlers per vedere quali idee sbagliate potresti avere.

Per quanto riguarda i consigli pratici:

• Se i tuoi valori hanno dimensioni alquanto arbitrarie e non si adattano int, usa long. Se non si adattano longall'uso BigInteger.

• Utilizzare i tipi più piccoli solo per gli array quando è necessario risparmiare spazio.

• Se hai bisogno esattamente di 64/32/16/8 bit, usa long/ int/ short/ bytee smetti di preoccuparti del bit di segno, tranne divisione, confronto, spostamento a destra e casting.

Vedi anche questa risposta sul "porting di un generatore di numeri casuali da C a Java".

Con JDK8 ha qualche supporto per loro.

Potremmo ancora vedere il pieno supporto di tipi senza segno in Java nonostante le preoccupazioni di Gosling.

So che questo post è troppo vecchio; tuttavia per il tuo interesse, in Java 8 e versioni successive, puoi utilizzare il inttipo di dati per rappresentare un numero intero a 32 bit senza segno, che ha un valore minimo di 0 e un valore massimo di 2 ³² −1. Utilizzare la Integerclasse per utilizzare il inttipo di dati come numero intero senza segno e sono stati aggiunti alla classe metodi statici come compareUnsigned(), divideUnsigned()ecc. IntegerPer supportare le operazioni aritmetiche per numeri interi senza segno.

Ho sentito storie che dovevano essere incluse vicino alla versione originale di Java. Oak è stato il precursore di Java, e in alcuni documenti di specifiche si parlava di valori usati. Sfortunatamente, questi non sono mai arrivati ​​al linguaggio Java. Per quanto qualcuno è stato in grado di capire che non sono stati implementati, probabilmente a causa di un limite di tempo.

Una volta ho seguito un corso C ++ con qualcuno nel comitato per gli standard C ++ che mi ha insinuato che Java ha preso la decisione giusta per evitare di avere numeri interi senza segno perché (1) la maggior parte dei programmi che usano numeri interi senza segno possono fare altrettanto con numeri interi firmati e questo è più naturale in termini di come la gente pensa e (2) l'utilizzo di numeri interi senza segno si traduce in molti problemi facili da creare ma difficili da eseguire il debug come l'overflow aritmetico dei numeri interi e la perdita di bit significativi durante la conversione tra tipi con segno e senza segno. Se si sottrae erroneamente 1 da 0 utilizzando numeri interi con segno, spesso si verifica un arresto più rapido del programma e si rende più facile trovare il bug che se si avvolge a 2 ^ 32 - 1, e compilatori e strumenti di analisi statica e controlli di runtime devono supponi di sapere cosa stai facendo da quando hai scelto di usare l'aritmetica senza segno. Anche,

Molto tempo fa, quando la memoria era limitata e i processori non funzionavano automaticamente su 64 bit contemporaneamente, ogni bit contava molto di più, quindi avere firmati vs byte non firmati o pantaloncini contava molto più spesso ed era ovviamente la giusta decisione di progettazione. Oggi solo usare un int firmato è più che sufficiente in quasi tutti i normali casi di programmazione e se il tuo programma ha davvero bisogno di usare valori maggiori di 2 ^ 31 - 1, spesso vuoi solo un lungo comunque. Una volta che sei nel territorio dell'utilizzo dei long, è ancora più difficile trovare un motivo per cui non riesci davvero a cavartela con 2 ^ 63 - 1 numeri interi positivi. Ogni volta che andremo ai processori a 128 bit sarà ancora meno un problema.

La tua domanda è "Perché Java non supporta gli integ non firmati"?

E la mia risposta alla tua domanda è che Java vuole che tutti i suoi tipi primitivi: byte , char , short , int e long debbano essere trattati rispettivamente come byte , word , dword e qword , esattamente come nell'assembly, e gli operatori Java sono firmati operazioni su tutti i suoi tipi primitivi ad eccezione di char , ma solo su char sono senza segno solo a 16 bit.

Quindi i metodi statici suppongono di essere le operazioni senza segno anche per 32 e 64 bit.

È necessaria la classe finale, i cui metodi statici possono essere chiamati per le operazioni non firmate .

Puoi creare questa classe finale, chiamarla come vuoi e implementare i suoi metodi statici.

Se non hai idea di come implementare i metodi statici, questo link potrebbe aiutarti.

A mio parere, Java è non è simile a C ++ a tutti , se non supporta i tipi senza segno né l'overloading degli operatori, quindi penso che Java deve essere trattato come linguaggio completamente diverso sia da C ++ e da C.

A proposito, è anche completamente diverso nel nome delle lingue.

Quindi non consiglio a Java di digitare un codice simile a C e non consiglio di digitare un codice simile a C ++, perché in Java non potrai fare quello che vuoi fare in C ++, cioè il codice non continuerà ad essere C ++ come per niente e per me è un male codificare in quel modo, per cambiare lo stile nel mezzo.

Consiglio di scrivere e usare metodi statici anche per le operazioni firmate, quindi non vedete nella combinazione di codice di operatori e metodi statici per operazioni firmate e non firmate, a meno che non siano necessarie solo operazioni firmate nel codice, e va bene utilizzare solo gli operatori.

Inoltre consiglio di evitare l'uso di tipi primitivi short , int e long e di utilizzare rispettivamente word , dword e qword , e si sta per chiamare i metodi statici per operazioni senza segno e / o operazioni con segno invece di usare operatori.

Se stai per eseguire solo operazioni firmate e utilizzare gli operatori solo nel codice, va bene usare questi tipi primitivi short , int e long .

In realtà la parola , DWORD e QWORD non non esiste nella lingua, ma è possibile creare nuova classe per ciascuno e per l'attuazione di ogni dovrebbe essere molto semplice:

La classe di parola detiene il tipo primitivo breve solo, la classe DWORD detiene il tipo primitivo int solo e la classe QWORD detiene il tipo primitivo lungo solo. Ora tutti i metodi senza segno e firmati come statici o meno come la tua scelta, puoi implementare in ogni classe, cioè tutte le operazioni a 16 bit sia senza segno che firmate dando nomi significativi sulla classe di parole , tutte le operazioni a 32 bit sia senza segno che con firmato dando nomi di significato sulla classe dword e tutte le operazioni a 64 bit sia senza segno che firmato dando nomi di significato sulla classe qword .

Se non ti piace dare troppi nomi diversi per ogni metodo, puoi sempre usare il sovraccarico in Java, bene leggere che Java non lo ha rimosso!

Se desideri metodi anziché operatori per operazioni con segno a 8 bit e metodi per operazioni senza segno a 8 bit che non hanno alcun operatore, puoi creare la classe Byte (nota che la prima lettera 'B' è maiuscola, quindi questa non è la byte di tipo primitivo ) e implementare i metodi in questa classe.

Informazioni sul passaggio per valore e passaggio per riferimento:

Se non sbaglio, come in C #, gli oggetti primitivi vengono passati per valore in modo naturale, ma gli oggetti di classe vengono passati per riferimento in modo naturale, quindi ciò significa che gli oggetti di tipo Byte , word , dword e qword verranno passati per riferimento e non per valore per impostazione predefinita. Vorrei che Java avesse oggetti struct come C #, quindi tutti i byte , word , dword e qword potevano essere implementati per essere strutt invece che di classe, quindi per impostazione predefinita sono stati passati per valore e non per riferimento per impostazione predefinita, come qualsiasi oggetto struct in C #, come i tipi primitivi, vengono passati per valore e non per riferimento per impostazione predefinita, ma poiché Java è peggiore di C # e abbiamo per far fronte a questo, allora ci sono solo classi e interfacce, che vengono passate per riferimento e non per valore per impostazione predefinita. Quindi, se vuoi passare oggetti Byte , word , dword e qword per valore e non per riferimento, come qualsiasi altro oggetto di classe in Java e anche in C #, dovrai semplicemente usare il costruttore di copie e il gioco è fatto.

Questa è l'unica soluzione a cui posso pensare. Vorrei solo poter digitare i tipi primitivi in ​​word, dword e qword, ma Java non supporta typedef né utilizza affatto, diversamente da C # che supporta l' utilizzo , che equivale al typedef di C.

Informazioni sull'output:

Per la stessa sequenza di bit , puoi stamparli in molti modi: come binario, come decimale (come il significato di% u in C printf), come ottale (come il significato di% o in C printf), come esadecimale (come il significato di% x in C printf) e come numero intero (come il significato di% d in C printf).

Si noti che C printf non conosce il tipo di variabili che vengono passate come parametri alla funzione, quindi printf conosce il tipo di ogni variabile solo dall'oggetto char * passato al primo parametro della funzione.

Quindi in ciascuna delle classi: byte , word , dword e qword , è possibile implementare il metodo di stampa e ottenere la funzionalità di printf, anche se il tipo primitivo della classe è firmato, è comunque possibile stamparlo come non firmato seguendo alcuni algoritmi che coinvolgono operazioni logiche e di spostamento per far stampare le cifre sull'output.

Sfortunatamente il link che ti ho fornito non mostra come implementare questi metodi di stampa, ma sono sicuro che puoi cercare su Google gli algoritmi necessari per implementare questi metodi di stampa.

Questo è tutto ciò che posso rispondere alla tua domanda e suggerirti.

Perché il unsignedtipo è puro male.

Il fatto che in C unsigned - intproduca unsignedè ancora più malvagio.

Ecco un'istantanea del problema che mi ha bruciato più di una volta:

// We have odd positive number of rays, 
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );

// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
    // Compute the angle between nth ray and the middle one.
    // The index of the middle one is (rays.size() - 1) / 2,
    // the rays are evenly spaced at angle delta, therefore
    // the magnitude of the angle between nth ray and the 
    // middle one is: 
    double angle = delta * fabs( n - (rays.size() - 1) / 2 ); 

    // Do something else ...
}

Hai già notato il bug? Confesso di averlo visto solo dopo essere intervenuto con il debugger.

Poiché nè di tipo senza segno, size_tl'intera espressione viene n - (rays.size() - 1) / 2valutata come unsigned. Quell'espressione vuole essere una posizione firmata del nraggio dal medio: il primo raggio dal medio sul lato sinistro avrebbe la posizione -1, il primo sulla destra avrebbe la posizione +1, ecc. Dopo prendendo il valore degli addominali e moltiplicandolo per l' deltaangolo otterrei l'angolo tra nil raggio th e quello medio.

Sfortunatamente per me l'espressione sopra conteneva il male non firmato e invece di valutare, diciamo -1, ha valutato 2 ^ 32-1. La successiva conversione in doublesigillato il bug.

Dopo uno o due bug causati da un uso improprio unsigneddell'aritmetica, bisogna cominciare a chiedersi se il bit extra che si ottiene valga la pena. Sto cercando, per quanto possibile, di evitare qualsiasi unsignedtipo di utilizzo in aritmetica, anche se lo uso ancora per operazioni non aritmetiche come le maschere binarie.

Ci sono alcune gemme nelle specifiche 'C' che Java ha lasciato cadere per ragioni pragmatiche ma che lentamente stanno tornando indietro con la domanda degli sviluppatori (chiusure, ecc.).

Ne cito un primo perché è legato a questa discussione; l'adesione dei valori del puntatore all'aritmetica di numeri interi senza segno. E, in relazione a questo argomento di discussione, la difficoltà di mantenere la semantica Unsigned nel mondo firmato di Java.

Immagino che se si dovesse ottenere un alter ego di Dennis Ritchie per avvisare il team di progettazione di Gosling che avrebbe suggerito di dare a Signed uno "zero all'infinito", in modo che tutte le richieste di offset degli indirizzi aggiungessero prima la loro DIMENSIONE ANELLO ALGEBRAICO per ovviare a valori negativi.

In questo modo, qualsiasi offset generato dall'array non può mai generare un SEGFAULT. Ad esempio in una classe incapsulata che chiamo RingArray di doppi che ha bisogno di un comportamento senza segno - nel contesto del "ciclo auto-rotante"

// ...
// 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
// ...

Il precedente RingArray non avrebbe mai "ottenuto" da un indice negativo, anche se un richiedente malintenzionato ci avesse provato. Ricorda, ci sono anche molte richieste legittime per chiedere valori indice precedenti (negativi).

NB: il modulo% esterno rimanda a richieste legittime mentre il modulo% interno maschera la palese negligenza dai negativi più negativi del modulo. Se mai dovesse apparire in un Java + .. + 9 || 8 + .. + spec, quindi il problema diventerebbe davvero un 'programmatore che non può "auto-ruotare" GUASTO'.

Sono sicuro che la cosiddetta "deficienza" di Java senza segno può essere compensata con il sopra descritto.

PS: Giusto per dare un contesto alla precedente pulizia RingArray, ecco un'operazione candidata 'set' per abbinare l'operazione sopra 'get' dell'elemento:

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
}

Mi viene in mente uno sfortunato effetto collaterale. Nei database Java integrati, il numero di ID che è possibile avere con un campo ID a 32 bit è 2 ^ 31, non 2 ^ 32 (~ 2 miliardi, non ~ 4 miliardi).

Il motivo per cui l'IMHO è perché sono / erano troppo pigri per implementare / correggere quell'errore. Suggerire che i programmatori C / C ++ non capisce unsigned, struttura, unione, bit flag ... È semplicemente assurdo.

Ether stavi parlando con un programmatore di base / bash / java sul punto di iniziare a programmare alla C, senza alcuna reale conoscenza di questa lingua o stai semplicemente parlando fuori di testa. ;)

quando ti occupi quotidianamente del formato, sia dal file che dall'hardware, inizi a mettere in discussione cosa diavolo stessero pensando.

Un buon esempio qui sarebbe provare a usare un byte senza segno come un loop auto-rotante. Per quelli di voi che non comprendono l'ultima frase, come mai ti definisci programmatore.

DC