É um int um inteiro de 64 bits em 64-bit C #?

StackOverflow https://stackoverflow.com/questions/164643

  •  03-07-2019
  •  | 
  •  

Pergunta

No meu código # fonte C posso ter declarado inteiros como: 

int i = 5;

ou 

Int32 i = 5;

No mundo de 32 bits atualmente prevalente eles são equivalentes. No entanto, à medida que caminhamos para um mundo de 64 bits, estou correto em dizer que a seguir irá tornar-se o mesmo? 

int i = 5;
Int64 i = 5;
Foi útil?

Solução

No. A especificação # C define rigidamente que int é uma abreviatura para System.Int32 com exactamente 32 bits. Alterar este seria um principal quebrando mudança.

Outras dicas

A palavra-chave int em C # é definido como um nome alternativo para o tipo System.Int32 e esta é (a julgar pelo nome) destina-se a ser um número inteiro de 32-bit. Para a especificação:

CLI especificação seção 8.2.2 (Built-in tipos de valor e de referência) tem uma mesa com o seguinte:

  • System.Int32 - assinado de 32 bits inteiro

C # especificação seção 8.2.1 (tipos predefinidos) tem uma tabela semelhante:

  • int - 32-bit assinado tipo integral

Isso garante que tanto System.Int32 em CLR e int em C # será sempre de 32 bits.

Will sizeof (testInt) nunca ser 8?

Não, sizeof (testInt) é um erro. testInt é uma variável local. O operador sizeof requer um tipo como seu argumento. Isso nunca será de 8, porque ele será sempre um erro.

VS2010 compila um c # inteiro gerido como 4 bytes, mesmo em uma máquina de 64 bits.

Correto. Faço notar que a secção 18.5.8 do sizeof(int) C # especificação define como sendo a constante de tempo de compilação 4. Ou seja, quando você diz sizeof(int) o compilador simplesmente substitui isso com 4; é como se você tivesse dito "4" no código-fonte.

Alguém sabe se / quando virá o tempo em que um "int" padrão em C # será 64 bits?

Nunca. Seção 4.1.4 dos estados de especificação C # que "int" é um sinônimo para "System.Int32".

Se o que você quer é um "inteiro ponteiro-sized", em seguida, usar IntPtr. Um IntPtr muda de tamanho em arquiteturas diferentes.

int é sempre sinônimo de Int32 em todas as plataformas.

É muito improvável que a Microsoft vai mudar isso no futuro, uma vez que iria quebrar um monte de código existente que assume int é de 32-bits.

Eu acho que você pode ser confundido por é que int é um alias para Int32 por isso será sempre 4 bytes, mas IntPtr é supor para coincidir com o tamanho da palavra da arquitetura CPU por isso vai ser 4 bytes em um 32- sistema de bits e 8 bytes em um sistema de 64 bits.

De acordo com a C # especificação ECMA-334 , seção "11.1.4 Tipos simples", a palavra int reservada será alias para System.Int32. Uma vez que este está na especificação é muito improvável a mudança.

Não importa se você estiver usando a versão de 32-bit ou 64-bit versão do CLR, em C # uma int sempre System.Int32 média e long será sempre System.Int64 média.

A seguir irá ser sempre verdadeira em C #:

sbyte assinados de 8 bits, 1 byte

byte 8 bits sem sinal, um byte

curtos assinados 16 bits, 2 bytes

ushort sem sinal de 16 bits, 2 bytes

int assinados 32 bits, 4 bytes

uint sem sinal de 32 bits, quatro bytes

longos assinados 64 bits, 8 bytes

ulong sem sinal de 64 bits, oito bytes

Um inteiro literal é apenas uma seqüência de dígitos (por exemplo 314159) sem qualquer um desses tipos explícitos. C # atribui o primeiro tipo de sequência ( int , uint , longa , ulong ) em que ele se adapta . Esta parece ter sido um pouco confusa em pelo menos uma das respostas acima.

Estranhamente o unário operador menos (sinal de menos), mostrando-se antes de uma seqüência de dígitos não reduzir a escolha de ( int , longo ) . A literal é sempre positivo; o sinal negativo é realmente um operador. Então, presumivelmente -314159 é exatamente a mesma coisa que -((int)314159). Exceto, aparentemente, há um caso especial para obter -2147483648 direto para um int ; caso contrário ele seria -((uint)2147483648). Que presumo faz algo desagradável.

De alguma forma parece seguro prever que o C # (e amigos) nunca vai se preocupar com os tipos "nome mole" para> = 128 bit inteiros. Nós vamos chegar bom suporte para arbitrariamente grandes inteiros e suporte super-precisos para UInt128, UInt256, etc. assim que processadores suportam a fazer matemática que largura, e quase nunca usar qualquer uma delas. espaços de endereços de 64 bits são realmente grande. Se eles são sempre muito pequeno que vai ser por alguma razão esotérica como ASLR ou um MapReduce mais eficiente ou algo assim.

Sim, como disse Jon, e ao contrário do 'mundo C / C ++', Java e C # não são dependentes do sistema que está sendo executado. Eles têm comprimentos de byte estritamente definido / short / int / long e / duplos carros alegóricos precisão única, igual em todos os sistemas.

int sem sufixo pode ser 32 ou 64 bits, que depende do valor que ela representa.

conforme definido no MSDN:

Quando um literal inteiro tem nenhum sufixo, seu tipo é o primeiro desses tipos em que o seu valor pode ser representado:. Int, uint, longo, ulong

Aqui está o endereço: https://msdn.microsoft.com/en-us/library/5kzh1b5w.aspx

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top