valor máximo de entero

291

En C, el número entero (para la máquina de 32 bits) es de 32 bits y oscila entre -32,768 y +32,767. En Java, el entero (largo) también es de 32 bits, pero varía de -2,147,483,648 a +2,147,483,647.

No entiendo cómo el rango es diferente en Java, a pesar de que el número de bits es el mismo. ¿Alguien puede explicar esto?

stackuser
fuente
35
Para obtener los valores máximo y mínimo de int en Java, use Integer.MAX_VALUE e Integer.MIN_VALUE
live-love
55
@stackuser - Algunas buenas respuestas a tu pregunta - deberías aceptar una :)
Darragh Enright
2
@DarraghEnright fue visto por última vez en marzo de 2015, dudo que vuelva :(
Ungeheuer
44
@ Adrian jaja - ¡Supongo que no! Sucede un poco, supongo. Siempre imaginé que SO podría aceptar respuestas automáticas fácilmente bajo ciertas condiciones: cuando la pregunta supera una cierta edad, el OP es AWOL y hay una respuesta claramente útil con un alto número de votos a favor.
Darragh Enright
2
@DarraghEnright De acuerdo. Pero OP estuvo aquí hace ~ 2 semanas, tuvo la oportunidad de aceptar, así que técnicamente no está lejos.
gaborsch

Respuestas:

392

En C , el lenguaje en sí no determina la representación de ciertos tipos de datos. Puede variar de máquina a máquina, en sistemas integrados intpuede tener 16 bits de ancho, aunque generalmente es de 32 bits.

El único requisito es que short int<= int<= long intpor tamaño. Además, hay una recomendación que intdebe representar la capacidad nativa del procesador .

Todos los tipos están firmados. El unsignedmodificador le permite utilizar el bit más alto como parte del valor (de lo contrario, está reservado para el bit de signo).

Aquí hay una breve tabla de los posibles valores para los posibles tipos de datos:

          width                     minimum                         maximum
signed    8 bit                        -128                            +127
signed   16 bit                     -32 768                         +32 767
signed   32 bit              -2 147 483 648                  +2 147 483 647
signed   64 bit  -9 223 372 036 854 775 808      +9 223 372 036 854 775 807
unsigned  8 bit                           0                            +255
unsigned 16 bit                           0                         +65 535
unsigned 32 bit                           0                  +4 294 967 295
unsigned 64 bit                           0     +18 446 744 073 709 551 615

En Java , la Especificación del lenguaje Java determina la representación de los tipos de datos.

El orden es: byte8 bits, short16 bits, int32 bits, long64 bits. Todos estos tipos están firmados , no hay versiones sin firmar. Sin embargo, las manipulaciones de bits tratan los números como si no estuvieran firmados (es decir, manejando todos los bits correctamente).

El tipo de datos de caracteres chares de 16 bits de ancho, sin signo y contiene caracteres con codificación UTF-16 (sin embargo, es posible asignar un charentero arbitrario de 16 bits sin signo que represente un punto de código de caracteres no válido)

          width                     minimum                         maximum

SIGNED
byte:     8 bit                        -128                            +127
short:   16 bit                     -32 768                         +32 767
int:     32 bit              -2 147 483 648                  +2 147 483 647
long:    64 bit  -9 223 372 036 854 775 808      +9 223 372 036 854 775 807

UNSIGNED
char     16 bit                           0                         +65 535
gaborsch
fuente
10
El estándar C también especifica valores mínimos para INT_MAX, LONG_MAX, etc.
Oliver Charlesworth
13
Java 8 ahora también tiene Entero sin firmar: docs.oracle.com/javase/8/docs/api/java/lang/Integer.html
Jakub Kotowski
44
Gracias, @jkbkot, es bueno saber eso. Aunque parece que la representación todavía está firmada, ciertas operaciones sin firmar se implementan como una función. Es difícil agregar dos ints sin firmar ...
gaborsch
55
@GaborSch En Java, int foo = Integer.MAX_VALUE + 1; System.out.println(Integer.toUnsignedLong(foo));imprime 2147483648y char es un tipo sin signo
aullador
2
@howlger Integer.MAX_VALUE + 1está 0x80000000en hexadecimal, debido al desbordamiento (y es igual a Integer.MIN_VALUE). Si lo convierte en sin signo (largo), el bit de signo se tratará como un bit de valor, por lo que lo será 2147483648. Gracias por la charnota charno está firmado, tienes razón, pero char no se usa realmente para los cálculos, por eso lo dejé de la lista.
gaborsch
72

En C, el número entero (para máquina de 32 bits) es de 32 bits y varía de -32768 a +32767.

Incorrecto. El entero con signo de 32 bits en la representación del complemento a 2 tiene el rango -2 31 a 2 31 -1 que es igual a -2,147,483,648 a 2,147,483,647.

Kos
fuente
3
Arreglé su exponenciación, **ni siquiera es C y, en mi opinión, no es muy clara. :)
Relájese
2
Se ve mejor ahora, gracias! Demasiado Python, supongo. Evito ^ya que suele serxor
Kos
55
Creo que mi punto es que, dado que C no tiene un operador de exponenciación, no creo que esa pieza en particular deba formatearse como código. :)
Relájate
19

Un número entero de 32 bits varía de -2,147,483,648 a 2,147,483,647. Sin embargo, el hecho de que esté en una máquina de 32 bits no significa que su Ccompilador use enteros de 32 bits.

Ivaylo Strandjev
fuente
1
Al menos mi copia del Sr. Kernighan y el Sr. Ritchies "El lenguaje de programación C" dice en A4.2 que intes del "ancho natural de la máquina" que interpretaría como 32 bits al compilar para máquinas de 32 bits.
junix
77
Esto depende del compilador, no de la máquina, creo. Tenía un compilador de 16 bits instalado en mi máquina de 64 bits, por ejemplo.
Ivaylo Strandjev
Por supuesto, su compilador de 16 bits para código x86 de 16 bits solo usó 16 bits. Pero ese no era mi punto. Incluso un procesador x86 de 32 bits que se ejecuta en modo de 16 bits tiene una capacidad nativa de solo 16 bits. Mi punto es que la plataforma objetivo del compilador tiene importancia. Por ejemplo, si tiene un compilador para su 80286, seguirá generando código de 16 bits y, por lo tanto, tendrá enteros de 16 bits.
junix
2
@junix Creo que eso es exactamente lo que señalo en mi respuesta. No es el sistema operativo el que especifica cuántos bits tienen sus enteros. La plataforma de destino es una propiedad del compilador, no del sistema operativo en el que está trabajando o del procesador que tiene.
Ivaylo Strandjev
Como escribí en mi primer comentario. "Son 32 bits al compilar para máquinas de 32 bits". El OP escribe en su publicación "el número entero (para máquina de 32 bits)" Entonces, por lo que entiendo, no se está refiriendo a su sistema operativo, o su máquina, se está refiriendo a su plataforma de destino
junix
15

La definición del lenguaje C especifica rangos mínimos para varios tipos de datos. Para int, este rango mínimo es -32767 a 32767, lo que significa que intdebe tener al menos 16 bits de ancho. Una implementación es libre de proporcionar un inttipo más amplio con un rango correspondientemente más amplio. Por ejemplo, en el servidor de desarrollo SLES 10 en el que trabajo, el rango es de -2147483647 a 2137483647.

Todavía hay algunos sistemas que usan inttipos de 16 bits (Todo el mundo no es un VAX x86), pero hay muchos que usan inttipos de 32 bits , y tal vez algunos que usan 64 bits.

El lenguaje C fue diseñado para ejecutarse en diferentes arquitecturas. Java fue diseñado para ejecutarse en una máquina virtual que oculta esas diferencias arquitectónicas.

John Bode
fuente
Para int de 16 bits, es -3276 8 a 32767. Para int de 32 bits, es -214748364 8 a 2147483647. El rango se especifica de -2 ^ (n bits-1) a + 2 ^ (n bits-1 ) - 1.
mythicalcoder
3
@Maven: 5.2.4.2.1 - INT_MINse especifica como -32767. No asumas el complemento de dos.
John Bode
8

El equivalente estricto de Java intestá long inten C.

Editar: si int32_testá definido, entonces es el equivalente en términos de precisión. long intGarantizar la precisión de Java int, ya que se garantiza que tenga al menos 32 bits de tamaño.

UmNyobe
fuente
tienes razón, el equivalente es int32_tsi está definido por tu compilador
UmNyobe
7

Esto se debe a que en C - entero en la máquina de 32 bits no significa que se usen 32 bits para almacenarlo, también puede ser de 16 bits. Depende de la máquina (depende de la implementación).

Lechuga Azul16
fuente
1
Bueno, vale la pena señalar que el comportamiento de implementación típico es usar "ancho de máquina" para int. Pero limits.hayuda a descubrir cuál es la verdad exacta
junix
3
Pero en realidad, no creo que se haya hecho un compilador de C para 32 sin int como 32 bits. El estándar puede permitir que la implementación del compilador int sea de naturaleza tonta, pero por alguna razón, nadie quiere hacer un compilador de C tonto. La tendencia es hacer compiladores de C útiles.
Lundin
4

En realidad el tamaño en bits del int, short, long depende de la implementación del compilador.

Por ejemplo, en mi Ubuntu 64 bit que tengo shorten 32bits, cuando en otra versión de Ubuntu de 32 16bits es bit.

Alex
fuente
2

En realidad es muy simple de entender, incluso puede calcularlo con la calculadora de Google: tiene 32 bits para un int y las computadoras son binarias, por lo tanto, puede tener 2 valores por bit (spot). si calcula 2 ^ 32 obtendrá 4.294.967.296. así que si divide este número entre 2 (porque la mitad de ellos son enteros negativos y la otra mitad son positivos), entonces obtiene 2,147,483,648. y este número es el int más grande que puede representarse por 32 bits, aunque si prestas atención notarás que 2,147,483,648 es mayor que 2,147,483,647 por 1, esto se debe a que uno de los números representa 0 que está en el medio desafortunadamente 2 ^ 32 no es un número impar, por lo tanto, no tiene solo un número en el medio, por lo que los enteros positivos tienen una cifra menos, mientras que los negativos obtienen la mitad completa 2,147,483,648.

Y eso es. Depende de la máquina, no del idioma.

Emos Turi
fuente
2
Esto no es lo que pidió ... la pregunta es "¿por qué C int es diferente de Java int?"
ElectronWill
Y en Java, el tamaño de int no depende de la máquina. int== 32 bits con signo, el complemento a dos está definido por la especificación del lenguaje Java y está grabado en hojas de unobtainium anodizado . (OK, tal vez no sea el último bit.)
Stephen C
1

En el rango C para __int32 es –2147483648 a 2147483647. Vea aquí los rangos completos.

unsigned short 0 to 65535
signed short 32768 to 32767
unsigned long 0 to 4294967295
signed long 2147483648 to 2147483647

No hay garantías de que un 'int' sea de 32 bits, si desea usar variables de un tamaño específico, particularmente al escribir código que involucra manipulaciones de bits, debe usar los 'Tipos enteros estándar'.

En java

El tipo de datos int es un entero de dos con signo de 32 bits. Tiene un valor mínimo de -2,147,483,648 y un valor máximo de 2,147,483,647 (inclusive).

Achintya Jha
fuente
2
Los valores que cita para C son solo rangos mínimos.
Oliver Charlesworth
@OliCharlesworth Rango si es de mínimo a máximo.
Achintya Jha
66
Lo que quiero decir es que el rango para cada tipo puede ser mayor que el que has citado anteriormente.
Oliver Charlesworth
3
No hay nada en C llamado __int32. Microsoft no tiene un compilador C estrictamente conforme, entonces, ¿a quién le importa cómo funciona su compilador que no es C? La única fuente relevante es ISO9899, ​​ya sea 5.2.4.2.1 "Tamaños de tipos enteros" o 7.20.2.1 "Límites de tipos enteros de ancho exacto". Ninguno de los cuales es compatible con el goo de Microsoft.
Lundin
2
C99 agrega int32_t, int16_t, etc., al estándar. No es 100% compatible con las adiciones de Microsoft, pero funcionan de manera similar.
Pregunte por Monica
-1

en el estándar C, puede usar INT_MAX como el valor 'int' máximo, esta constante debe definirse en "limits.h". Constantes similares se definen para otros tipos ( http://www.acm.uiuc.edu/webmonkeys/book/c_guide/2.5.html ), como se indicó, estas constantes dependen de la implementación pero tienen un valor mínimo de acuerdo con los bits mínimos para cada tipo, como se especifica en la norma.

Carlos UA
fuente
55
Esto realmente no llega a abordar la pregunta del OP. Además, las partes centrales de una respuesta realmente no deberían enterrarse en otro sitio.
Brad Koch