Después de todo este tiempo, nunca pensé en hacer esta pregunta; Entiendo que esto vino de C++, pero lo que era el razonamiento detrás de él:¿De dónde provienen las notaciones octal/hex?
¿Por qué 0? ¿Por qué 0x? ¿Hay una progresión natural para base-32?
C, el antepasado de C++ y Java, fue desarrollado originalmente por Dennis Richie en PDP-8 a principios de los 70. Esas máquinas tenían un 12-bit address space, por lo que los punteros (direcciones) tenían 12 bits de longitud y se representaban más convenientemente en código mediante tres dígitos octales de 4 bits (la primera palabra direccionable sería 000octal, la última palabra direccionable 777octal).
Octal no se asigna bien a los bytes de 8 bits porque cada dígito octal representa tres bits, por lo que siempre habrá bits en exceso representables en la notación octal. Un byte de bits totalmente TRUE (1111 1111) es 377 en octal, pero FF en hexadecimal.
Hex es más fácil para la mayoría de las personas convertir en binario en sus cabezas, ya que los números binarios generalmente se expresan en bloques de ocho (porque es del tamaño de un byte) y ocho son exactamente dos dígitos hexadecimales, pero la nota hexadecimal habría sido torpe y engañoso en el tiempo de Dennis (lo que implica la capacidad de abordar 16 bits). Los programadores necesitan pensar en binario cuando trabajan con hardware (para lo cual cada bit típicamente representa un cable físico) y cuando se trabaja con lógica bit-wise (para lo cual cada bit tiene un significado definido por el programador).
Imagino que Dennis agregó el prefijo 0 como la variación más simple posible en los números decimales diarios, y lo más fácil para los primeros analizadores sintácticos para distinguir.
Creo que la notación hexadecimal 0x__ se agregó a C un poco más tarde. El árbol de análisis sintáctico del compilador para distinguir 1-9 (primer dígito de una constante decimal), 0 (primer dígito [insignificante] de una constante octal), y 0x (que indica una constante hexadecimal a seguir en los dígitos subsiguientes) entre sí es considerablemente más más complicado que usar un 0 como indicador para pasar de analizar los dígitos subsiguientes como octal en lugar de decimal.
¿Por qué diseñó Dennis de esta manera? Contemporary programmers no aprecian que esas computadoras primitivas a menudo se controlaron alternar las instrucciones a la CPU al activar físicamente los interruptores en el panel frontal de la CPU, o con una tarjeta perforada o cinta de papel; todos los entornos en los que guardar algunos pasos o instrucciones representaban ahorros significativos de mano de obra. Además, la memoria era limitada y costosa, por lo que guardar incluso algunas instrucciones tenía un alto valor.
En resumen: 0 para octal porque era eficiente analizable y octal era fácil de manejar en PDP-8 (al menos para la manipulación de direcciones)
0x para hexagonal probablemente porque era compatible con versiones anteriores de forma natural y extensión en el estándar de prefijo octal y aún relativamente eficiente para analizar.
Creo que 0x en realidad vino para el mundo UNIX/Linux y fue recogido por C/C++ y otros idiomas. Pero no sé la razón exacta o el verdadero origen.
Cuando apareció en C, no existía Linux. No estoy seguro de cuántas versiones de Unix hay; podría haber sido solo de AT & T. –
¿Se escribió Unix ensamblado y Linux en C? –
0x definitivamente es post-unix y post-C. Tanto UNIX como C enviaron en 1976 sin él. parece haber aparecido en 1978 en "The C Programming Language", 1st Ed. –
lo sé ...
0 es para 0ctal
0x es para, así, que ya hemos usado para referirse a 0 octal y hay una x en hexadecimal de manera tapón que allí también
como para la progresión natural, mejor mirada a los últimos lenguajes de programación que puede afijo subíndices tales como
123_27 (interpretan _ en el sentido de subíndice)
y así sucesivamente
?
Marcos
+1 Eso tiene sentido para mí también. –
Lo mismo. Esta es precisamente la forma en que el resto de C fue "diseñado". –
** x ** suena como ** "ex **" que es Cockney del siglo XVIII para "literal numérico hexadecimal". – detly
El prefijo cero para octal y hexadecimal 0x para, son de los primeros días de Unix.
La razón de la existencia de octal data de cuando había hardware con bytes de 6 bits, lo que hizo que octal fuera la elección natural. Cada dígito octal representa 3 bits, por lo que un byte de 6 bits es dos dígitos octales. Lo mismo vale para el hex, a partir de bytes de 8 bits, donde un dígito hexadecimal es de 4 bits y, por lo tanto, un byte es de dos dígitos hexadecimales. El uso de octal para bytes de 8 bits requiere 3 dígitos octales, de los cuales el primero solo puede tener los valores 0, 1, 2 y 3 (el primer dígito es realmente 'tetral', no octal). No hay ninguna razón para ir a base32 a menos que alguien desarrolle un sistema en el que los bytes tengan una longitud de diez bits, por lo que un byte de diez bits podría representarse como dos "nybbles" de 5 bits.
Creo que la pregunta se relaciona con el origen de la sintaxis. –
¿Hay una progresión natural para base-32?
Esto es parte de la razón por Ada utiliza la forma 16 # para introducir constantes hexagonales, 8 # para octal, # 2 para binario, etc.
yo no preocuparme demasiado por necesidad de espacio para "crecimiento futuro" en la base sin embargo. Esto no es como RAM o espacio de direcciones donde necesita un orden de magnitud más cada generación.
De hecho, los estudios han demostrado que octal y hex son bastante el punto positivo para representaciones legibles por humanos que son compatibles con binarios. Si vas más abajo que octal, comienza a requerir un número ridículo de dígitos para representar números más grandes. Si vas más allá del hex, las tablas de matemáticas se vuelven ridículamente grandes. Hex es en realidad un poco demasiado, pero Octal tiene el problema de que no encaja en un byte.
Hay una codificación estándar para Base32. Es muy similar al Base64. Pero no es muy conveniente leer. Se usa hexadecimal porque se pueden usar 2 dígitos hexadecimales para representar un byte de 1 8 bits. Y octal se usaba principalmente para sistemas antiguos que usaban 12-bit bytes. Hizo una representación más compacta de los datos en comparación con mostrar los registros sin procesar como binarios.
También se debe tener en cuenta que algunos lenguajes usan o ### para octal y x ## o h ## para hexadecimal, así como, muchas otras variaciones.
Los "nuevos" números tenían que comenzar con un dígito, para trabajar con la sintaxis existente.
La práctica establecida tenía nombres de variables y otros identificadores que comenzaban con una letra (o algunos otros símbolos, tal vez subrayado o signo de dólar). Entonces, "a", "abc" y "a04" son todos nombres. Los números comenzaron con un dígito. Entonces "3" y "3e5" son números.
Cuando agrega cosas nuevas a un lenguaje de programación, intenta que quepan en la sintaxis, gramática y semántica existentes, e intenta que el código existente siga funcionando. Por lo tanto, no le conviene cambiar la sintaxis para hacer que "x34" sea un número hexadecimal o "o34" un número octal.
Entonces, ¿cómo se ajustan los números octales en esta sintaxis? Alguien se dio cuenta de que, a excepción de "0", no hay necesidad de numerales que comiencen con "0". Nadie necesita escribir "0123" para 123. Por lo tanto, usamos un cero para denotar los números octales.
¿Qué pasa con los números hexadecimales? Puede usar un sufijo, de modo que "34x" signifique 34 . Sin embargo, el analizador tiene que leer todo el camino hasta el final del número antes de saber cómo interpretar los dígitos (a menos que encuentre uno de los dígitos "a" a "f", que por supuesto indicará hexadecimal). Es "más fácil" para el analizador saber que el número es hexadecimal temprano. Pero todavía tiene que comenzar con un dígito, y el truco cero ya se ha utilizado, por lo que necesitamos algo más. "X" fue elegido, y ahora tenemos "0x" para hexadecimal.
(Lo anterior se basa en mi comprensión de análisis y un poco de historia general sobre el desarrollo del lenguaje, no en el conocimiento de las decisiones específicas hechas por los desarrolladores del compilador o comités de idiomas.)
Tengo que amar a alguien que habla de C++ como su historia antigua. –
No están presentes en BCPL o B. –
Venía de C, no de C++. C++ simplemente lo mantuvo, ya que Stroustrup no quería introducir incompatibilidades innecesarias entre C y C++. –