Domanda

Nel mio codice sorgente C # potrei aver dichiarato numeri interi come:

int i = 5;

o

Int32 i = 5;

Nel mondo a 32 bit attualmente prevalente sono equivalenti. Tuttavia, mentre ci spostiamo in un mondo a 64 bit, ho ragione nel dire che quanto segue diventerà lo stesso?

int i = 5;
Int64 i = 5;
È stato utile?

Soluzione

No. La specifica C # definisce rigidamente che int è un alias per System.Int32 con esattamente 32 bit. Cambiare questo sarebbe un cambiamento importante.

Altri suggerimenti

La parola chiave int in C # è definita come un alias per il tipo System.Int32 e questo (a giudicare dal nome) è inteso come un numero intero a 32 bit . Alla specifica:

  

Specifiche CLI sezione 8.2.2 (Valore incorporato e tipi di riferimento) ha una tabella con quanto segue:

     
      
  • System.Int32 - Numero intero a 32 bit firmato
  •   
     

Specifica C # sezione 8.2.1 (Tipi predefiniti) ha una tabella simile:

     
      
  • int - tipo integrale con segno a 32 bit
  •   

Ciò garantisce che sia System.Int32 in CLR sia int in C # saranno sempre a 32 bit.

  

sizeof (testInt) sarà mai 8?

No, sizeof (testInt) è un errore. testInt è una variabile locale. L'operatore sizeof richiede un tipo come argomento. Questo non sarà mai 8 perché sarà sempre un errore.

  

VS2010 compila un numero intero gestito c # come 4 byte, anche su una macchina a 64 bit.

Una corretta. Prendo atto che la sezione 18.5.8 della specifica C # definisce sizeof (int) come la costante di compilazione 4. Cioè, quando dici sizeof (int) il il compilatore sostituisce semplicemente quello con 4; è come se avessi detto "4" nel codice sorgente.

  

Qualcuno sa se / quando verrà il momento che uno standard "int" in C # saranno 64 bit?

Mai. La sezione 4.1.4 della specifica C # afferma che "int" è sinonimo di " System.Int32 " ;.

Se quello che vuoi è un intero di dimensioni "puntatore" " quindi usa IntPtr. Un IntPtr cambia dimensione su architetture diverse.

int è sempre sinonimo di Int32 su tutte le piattaforme.

È molto improbabile che Microsoft lo cambierà in futuro, poiché spezzerebbe molto del codice esistente che presuppone che int sia a 32 bit.

Penso che ciò di cui potresti essere confuso è che int è un alias per Int32 quindi sarà sempre di 4 byte, ma IntPtr si suppone che corrisponda alla dimensione della parola dell'architettura della CPU, quindi sarà di 4 byte su un sistema a 32 bit e 8 byte su un sistema a 64 bit.

Secondo la specifica C # ECMA-334 , sezione " 11.1.4 Tipi semplici " ;, la parola riservata int verrà modificata in System.Int32 . Poiché questo è nelle specifiche, è molto improbabile che cambi.

Indipendentemente dal fatto che tu stia utilizzando la versione a 32 bit o 64 bit del CLR, in C # un int significherà sempre System.Int32 e < code> long significherà sempre System.Int64 .

Quanto segue sarà sempre vero in C #:

sbyte firmato 8 bit, 1 byte

byte senza segno 8 bit, 1 byte

breve firmato 16 bit, 2 byte

ushort senza segno 16 bit, 2 byte

int firmato 32 bit, 4 byte

uint senza segno 32 bit, 4 byte

lungo firmato 64 bit, 8 byte

ulong senza segno 64 bit, 8 byte

Un intero letterale è solo una sequenza di cifre (ad es. 314159 ) senza nessuno di questi tipi espliciti. C # gli assegna il primo tipo nella sequenza ( int , uint , long , ulong ) in cui si adatta . Questo sembra essere stato leggermente confuso in almeno una delle risposte di cui sopra.

Weirdly the operatore meno unario (segno meno) che appare prima di una stringa di cifre non riduce la scelta a ( int , lungo ) . Il letterale è sempre positivo; il segno meno è davvero un operatore. Quindi presumibilmente -314159 è esattamente la stessa cosa di - ((int) 314159) . Tranne apparentemente c'è un caso speciale per ottenere -2147483648 direttamente in un int ; altrimenti sarebbe - ((uint) 2147483648) . Che presumo faccia qualcosa di spiacevole.

In qualche modo sembra sicuro prevedere che C # (e gli amici) non si preoccuperanno mai di "quotish squishy name" tipi per > = interi a 128 bit. Otterremo un buon supporto per arbitrariamente interi di grandi dimensioni e un supporto super preciso per UInt128, UInt256, ecc. Non appena i processori supportano la matematica in modo così ampio, e quasi mai ne usano. Gli spazi degli indirizzi a 64 bit sono davvero grandi. Se mai troppo piccoli lo saranno per qualche motivo esoterico come ASLR o un MapReduce più efficiente o qualcosa del genere.

Sì, come ha detto Jon, e diversamente dal 'mondo C / C ++', Java e C # non dipendono dal sistema su cui sono in esecuzione. Hanno lunghezze rigorosamente definite per float di precisione byte / short / int / long e single / double, uguali su tutti i sistemi.

int senza suffisso può essere a 32 bit o 64 bit, dipende dal valore che rappresenta.

come definito in MSDN:

  

Quando un intero letterale non ha suffisso, il suo tipo è il primo di questi tipi in cui può essere rappresentato il suo valore: int, uint, long, ulong.

Ecco l'indirizzo: https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top