2011-12-15 13 views
5

Stavo lavorando su un problema quando l'ho incontrato.Perché il cast di char in int funziona e non il char in Integer in Java

(int)input.charAt(i) //works 
(Integer)input.charAt(i) // Does not work 
// input being a string 

Il primo pensiero che ho sono i primitivi sono trattati in modo diverso ed è per questo che questo non funziona. Ma poi trovo difficile capire perché avrebbero una classe Integer Wrapper in primo luogo.

Modifica: Quali sono i vantaggi di avere classi wrapper, quindi? È solo per non avere una presenza primitiva ed essere più OO nel design? Sto trovando difficile capire come sono utili. Nuovo dubbio altogetehr.

+2

Interessante.Avrei pensato che potesse essere auto inscatolato. – DerMike

risposta

7

Hai ragione che le primitive sono trattate in modo diverso. Questa situazione funziona:

(Integer)(int)input.charAt(i); 

La differenza è che quando l'argomento è un int, (Integer)scatole il numero intero. In realtà non è un cast anche se sembra che sia. Ma se l'argomento è un char, allora sarebbe un tentativo cast; ma i primitivi non possono essere lanciati sugli oggetti e quindi non funziona. Che cosa è possibile do è prima di trasmettere il char a int - questo cast è corretto poiché entrambi sono tipi primitivi - e quindi il int può essere inserito.

Naturalmente, char ->Integer boxe poteva sono stati fatti lavorare. "Perchè no?" è una bella domanda Probabilmente ci sarebbe stato poco uso per tale caratteristica, specialmente quando la stessa funzione può essere ottenuta essendo un po 'più esplicito. (dovrebbe char ->Long funziona troppo, allora e char ->Short caratteri sono a 16 bit, quindi questo sarebbe più semplice??.)

Risposta da modificare: il vantaggio di classi wrapper è primitive che avvolte possono essere trattati come oggetti: memorizzati in un List<Integer>, per esempio. List<int> non funzionerebbe, perché int non è un oggetto. Quindi forse una domanda ancora più pertinente sarebbe, che cosa fanno i non-oggetti primitivi in ​​un linguaggio OO? La risposta è in termini di prestazioni: le primitive sono più veloci e richiedono meno memoria. Il caso d'uso determina se la convenienza degli oggetti o l'esecuzione delle primitive è più importante.

+0

Quindi non usare le primitive nelle raccolte accelera le prestazioni? – gizgok

+0

@gizgok: Non c'è modo di usare le primitive nelle raccolte perché le primitive non sono oggetti. Cioè, non puoi costruire un 'List ', non viene compilato. Le matrici primitive * sono comunque degli oggetti, quindi un 'List ' funzionerebbe, e sì, a seconda di cosa si fa con esso e di come, sarebbe almeno come o più performante come 'List '. –

2

Perché intero è un Object. e char non lo è. non puoi lanciare una cosa non Object su qualche oggetto.

Infatti non è possibile eseguire il cast di alcun oggetto su qualsiasi altro oggetto di classe che non si trova nella gerarchia di tale oggetto.

ad esempio, non si può fare questo

Integer g = (Integer) s; 

dove s è oggetto di String.

Ora perché chattare con int funziona, perché ogni carattere è rappresentato come unicode in java, quindi puoi pensarlo come backend char è una versione ridotta di int. (int è 32 bit e char è 16 bit)

+0

Vero ma pensavo che il pugilato automatico sarebbe successo. – gizgok

+0

boxing automatico è vero solo per ints. questo significa che non dovrai eseguire il cast esplicito quando converti un int in Integer. @gizgok – Zohaib