c++ - translator - ¿Se garantiza que ''long'' será de al menos 32 bits?

legal english vocabulary

Question

Al leer el Estándar C ++, siempre he entendido que los tamaños de los tipos fundamentales integrales en C ++ son los siguientes:

sizeof(char) <= sizeof(short int) <= sizeof(int) <= sizeof(long int)

Deduje esto de 3.9.1 / 2:

2. Hay cuatro tipos de entero con signo: "signed char", "short int", "int" y "long int." En esta lista, cada tipo proporciona al menos tanto almacenamiento como los que lo preceden en la lista. Los colores planos tienen el tamaño natural sugerido por la arquitectura del entorno de ejecución

Además, el tamaño de char es descrito por 3.9.1 / como siendo:

1. [...] lo suficientemente grande como para almacenar cualquier miembro del conjunto de caracteres básicos de la implementación.

1.7 / 1 define esto en términos más concretos:

1. La unidad de almacenamiento fundamental en el modelo de memoria C + + es el byte. Un byte es al menos lo suficientemente grande como para contener cualquier miembro del conjunto de caracteres de ejecución básico y está compuesto por una secuencia contigua de bits, cuyo número está definido por la implementación.

Esto me lleva a la siguiente conclusión:

1 == sizeof(char) <= sizeof(short int) <= sizeof(int) <= sizeof(long int)

donde sizeof nos dice cuántos bytes es el tipo. Además, está definido por la implementación cuántos bits hay en un byte. La mayoría de nosotros probablemente estamos acostumbrados a tratar bytes de 8 bits, pero el Estándar dice que hay n bits en un byte.

En esta publicación , Alf P. Steinbach dice:

largo está garantizado (al menos) 32 bits.

Esto va en contra de todo lo que entiendo el tamaño de los tipos fundamentales para estar en C ++ de acuerdo con el Estándar. Normalmente, descartaría esta afirmación porque un principiante está equivocado, pero como se trataba de Alf, decidí que valía la pena seguir investigando.

Entonces, ¿qué dices tú? ¿Es un largo garantizado por el estándar de al menos 32 bits? Si es así, sea específico sobre cómo se hace esta garantía. Simplemente no lo veo.

1. El estándar C ++ dice específicamente que para conocer C ++ debes saber C (1.2 / 1) ¹

2. El estándar de C ++ define implícitamente el límite mínimo en los valores que un long puede acomodarse para ser LONG_MIN - LONG_MAX ²

Entonces, no importa cuán grande sea, debe ser lo suficientemente grande para mantener LONG_MIN en LONG_MAX.

Pero Alf y otros son específicos de que un largo debe ser de al menos 32 bits. Esto es lo que intento establecer. El estándar de C ++ es explícito de que no se especifica el número de bits en un byte (podría ser 4, 8, 16, 42) Entonces, ¿cómo se hace la conexión para poder acomodar los números LONG_MIN-LONG_MAX a al menos 32 bits ?

(1) 1.2 / 1: los siguientes documentos referenciados son indispensables para la aplicación de este documento. Para las referencias con fecha, sólo se aplica la edición citada. Para las referencias sin fecha, se aplica la última edición del documento referenciado (incluidas las enmiendas).

• ISO / IEC 2382 (todas las partes), Tecnología de la información - Vocabulary
• ISO / CEI 9899: 1999, Lenguajes de programación - C
• ISO / CEI 10646-1: 2000, Tecnología de la información - Conjunto de caracteres codificados por octetos múltiples (UCS) universales - Parte 1: Arquitectura y plano multilingüe básico

(2) Definido en <climits> como:

LONG_MIN -2147483647 // -(2^31 - 1)
LONG_MAX [phone] //   2^31 - 1

Answer 1

Pero Alf y otros son específicos de que un largo debe ser de al menos 32 bits. Esto es lo que intento establecer. El estándar de C ++ es explícito de que no se especifica el número de bits en un byte. Podría ser 4, 8, 16, 42 ... Entonces, ¿cómo se hace la conexión al poder acomodar los números LONG_MIN-LONG_MAX a al menos 32 bits?

Necesita 32 bits en la representación del valor para obtener al menos ese número de patrones de bit. Y dado que C ++ requiere una representación binaria de enteros (lenguaje explícito a tal efecto en el estándar, §3.9.1 / 7), QED

Answer 2

C ++ utiliza los límites definidos en el estándar C (C ++: 18.3.2 (c.limits), C: 5.2.4.2.1):

LONG_MIN -2147483647 // -(2^31 - 1)
LONG_MAX [phone] //   2^31 - 1

Así que tienes garantizado que un largo es de al menos 32 bits.

Y si desea seguir la ruta larga y tortuosa para ver si LONG_MIN / LONG_MAX son representables por long , debe mirar 18.3.1.2 (numeric.limits.members) en el estándar de C ++:

static constexpr T min() throw(); // Equivalent to CHAR_MIN, SHRT_MIN, FLT_MIN, DBL_MIN, etc.
static constexpr T max() throw(); // Equivalent to CHAR_MAX, SHRT_MAX, FLT_MAX, DBL_MAX, etc.

Moví las notas al pie en el comentario, por lo que no es exactamente lo que aparece en el estándar. Pero básicamente implica que std::numeric_limits<long>::min()==LONG_MIN==(long)LONG_MIN y std::numeric_limits<long>::max()==LONG_MAX==(long)LONG_MAX .

Entonces, aunque el estándar de C ++ no especifica la representación bit a bit de números negativos (firmados), tiene que ser un complemento a dos y requiere 32 bits de almacenamiento en total, o tiene un bit de signo explícito que significa que tiene 32 bits de almacenamiento también.

Answer 3

El estándar C ++ observa que los contenidos de <climits> son los mismos que los del encabezado C <limits.h> (18.2.2 en ISO C ++ 03 doc).

Desafortunadamente, no tengo una copia del estándar C que existía antes de C ++ 98 (es decir, C90), pero en C99 (sección 5.2.4.2.1), <limits.h> debe tener al menos estos valores mínimos . No creo que esto haya cambiado de C90, aparte de C99 agregando los tipos long long .

— minimum value for an object of type long int

LONG_MIN -2147483647 // −(2^31 − 1)

— maximum value for an object of type long int

LONG_MAX [phone] // 2^31 − 1

— maximum value for an object of type unsigned long int

ULONG_MAX 4294967295 // 2^32 − 1

— minimum value for an object of type long long int

LLONG_MIN -9223372036854775807 // −(2^63− 1)

Answer 4

La respuesta es definitivamente SÍ. Lea mi OP y todos los comentarios para entender exactamente por qué, pero esta es la versión corta. Si dudas o cuestionas algo de esto, te animo a que leas todo el hilo y todos los comentarios. De lo contrario, acepte esto como verdadero:

1. El estándar de C ++ incluye partes del estándar C, incluidas las definiciones de LONG_MIN y LONG_MAX
2. LONG_MIN se define como no mayor que -2147483647
3. LONG_MAX se define como no menos de [phone]
4. En C ++, los tipos integrales se almacenan en binario en la representación subyacente
5. Para representar -2147483647 y [phone] en binario, necesita 32 bits.
6. Se garantiza que un C ++ long podrá representar el rango mínimo de LONG_MIN través de LONG_MAX

Por lo tanto, un long debe ser de al menos 32 bits ¹ .

EDITAR:

LONG_MIN y LONG_MAX tienen valores con magnitudes dictadas por el estándar C (ISO / IEC 9899: TC3) en la sección §5.2.4.2.1:

[...] Sus valores definidos por la implementación serán iguales o mayores en magnitud [...] (valor absoluto) a los mostrados, con el mismo signo [...]

— minimum value for an object of type long int
LONG_MIN -2147483647 // -(2 ^ 31 - 1)
— maximum value for an object of type long int
LONG_MAX [phone] // 2 ^ 31 - 1

¹ 32 bits : Esto no significa que sizeof (long) >= 4 , porque un byte no es necesariamente 8 bits. Según el estándar, un byte es un número de bits no especificado (definido por la plataforma). Si bien la mayoría de los lectores encontrarán esto extraño, hay hardware real en el que CHAR_BIT tiene 16 o 32.

Answer 5

Sí, el estándar de C ++ es explícito de que no se especifica el número de bits en un byte. El número de bits en un largo tampoco está especificado.

Establecer un límite inferior en un número no lo especifica .

El estándar C ++ dice, en un solo lugar:

1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long).

Dice, en efecto, en otro lugar, mediante la inclusión del estándar C:

CHAR_BITS >= 8; SHORT_BITS >= 16; INT_BITS >= 16; LONG_BITS >= 32

(excepto que AFAIK, los identificadores SHORT_BITS, INT_BITS y LONG_BITS no existen, y que estos límites se deducen por los requisitos para valores mínimos en los tipos).

Esto se desprende del hecho de que se requiere matemáticamente un cierto número de bits para codificar todos los valores en el rango LONG_MIN..LONG_MAX (por ejemplo, para longitudes).

Finalmente, los cortos, enteros y largos deben estar compuestos por un número integral de caracteres; sizeof () siempre informa un valor integral. Además, iterar a través de la memoria char por char debe acceder a cada bit, lo que pone algunas limitaciones prácticas.

Estos requisitos no son inconsistentes de ninguna manera . Cualquier tamaño que satisfaga los requisitos está bien.

Hubo máquinas hace mucho tiempo con un tamaño de palabra nativa de 36 bits. Si tuviera que portarles un compilador de C ++, podría legalmente decidir tener 9 bits en un carácter, 18 en ambos, corto e int, y 36 en largo. También podría decidir legalmente tener 36 bits en cada uno de esos tipos, por la misma razón que puede tener 32 bits en un int en un sistema típico de 32 bits en la actualidad. Hay implementaciones en el mundo real que usan caracteres de 64 bits.

Ver también las secciones 26.1-6 y 29.5 de C ++ FAQ Lite .