El motivo de typedef: ed primitive data types es abstraer la representación de bajo nivel y hacer que sea más fácil de comprender (uint64_t en lugar de long long tipo, que es de 8 bytes). No hay uint_fast32_t que tiene el mismo typedef que uint32_t. ¿El uso de la versión "rápida" hará que el programa sea más rápido?¿Qué es uint_fast32_t y por qué debería usarse en lugar del int normal y uint32_t?
int puede ser tan pequeño como 16 bits en algunas plataformas. Puede no ser suficiente para su aplicación.uint32_t no se garantiza que exista. Es un typedef opcional que la implementación debe proporcionar si tiene un tipo entero sin signo de exactamente 32 bits. Algunos tienen bytes de 9 bits, por ejemplo, por lo que no tienen un uint32_t.uint_fast32_t indica claramente su intención: es un tipo de al menos 32 bits, que es el mejor desde el punto de vista del rendimiento. uint_fast32_t puede ser de hecho de 64 bits de longitud. Depende de la implementación.... hay
uint_fast32_tque tiene el mismo typedef comouint32_t...
Lo que usted está buscando en no es la norma. Es una implementación particular (BlackBerry). Por lo tanto, no puede deducir de ahí que uint_fast32_t es siempre el mismo que uint32_t.
Consulte también:
Buena respuesta. Para completar, uno podría señalar la diferencia a 'uint_least32_t' también, que es lo mismo que' uint_fast32_t', excepto que favorece la tienda más pequeña en lugar de la velocidad. – Damon
¿Por qué el número entero más rápido que tiene al menos 32 bits de ancho es mayor que 32 bits? Siempre pensé que si había menos bits, habría menos bits en los que la CPU tendría que trabajar y, por lo tanto, sería más rápido. ¿Que me estoy perdiendo aqui? –
@ShaneHsu: supongamos que una CPU de 64 bits tendrá un bit de verano de 64 bits, que suma números de 64 bits en un ciclo. No importa si todo lo que quiere hacer es trabajar con números de 32 bits, no va a ser más rápido que un ciclo. Ahora, aunque no es así en x86/amd64, los enteros de 32 bits pueden no ser direccionables. En tal caso, trabajar en ellos requiere operaciones adicionales para extraer los 32 bits de, digamos, unidades alineadas de 64 bits. Ver también la pregunta vinculada. El estándar C++ está escrito para que funcione en una máquina que tenga palabras de 37 bits ... así que no hay ningún tipo de 32 bits. – ybungalobill
Cuando #include inttypes.h en su programa, se obtiene acceso a un montón de diferentes maneras para representar números enteros.
El tipo uint_fast * _t simplemente define el tipo más rápido para representar un número dado de bits.
Piénselo de esta manera: defina una variable del tipo short y úsela varias veces en el programa, que es totalmente válida. Sin embargo, el sistema en el que está trabajando podría funcionar más rápidamente con valores del tipo int. Al definir una variable como tipo uint_fast*t, la computadora simplemente elige la representación más eficiente con la que puede trabajar.
Si no hay diferencia entre estas representaciones, el sistema elige la que desee y la utiliza de manera uniforme.
¿Por qué inttypes.h y no stdint.h? Parece que inttypes.h solo contiene varias pelusas medianamente útiles, además de incluir stdint.h? – Lundin
@Lundin para ref: http://stackoverflow.com/a/9162072/2757035 –
@underscore_d Sé la diferencia. ¿Pero quién usa stdio.h en programas profesionales, sin importar el área de aplicación? – Lundin
La diferencia radica en su exactitud y disponibilidad.
El doc aquí dice:
unsigned tipo entero con anchura de exactamente 8, 16, 32 y 64 bits respectivamente (proporcionadas sólo si la implementación soporta directamente el tipo):
uint8_t uint16_t uint32_t uint64_t
Y
más rápido sin signo de tipo entero sin signo con anchura de al menos 8, 16, 32 y 64 bits respectivamente
uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t
Así que la diferencia es bastante claro que uint32_t es un tipo que tiene exactamente32 bits, y una implementación debe proporcionarlo solo si tiene un tipo con exactamente 32 bits, y luego puede escribir dede ese tipo como uint32_t. Esto significa que uint32_t puede o no ser disponible.
Por otro lado, uint_fast32_t es un tipo que tiene al menos 32 bits, lo que también significa que, si una aplicación puede typedef uint32_t como uint_fast32_tsi que proporciona uint32_t. Si no proporciona uint32_t, entonces uint_fast32_t podría ser un typedef de cualquier tipo que tenga al menos 32 bits.
¿Pero cuál es la razón por la cual uint_fast32_t es más rápido que uint32_t? ¿Por qué es más rápido? – Destructor
@PravasiMeet: no todos los enteros accedidos de la misma manera. Algunos son más fáciles de acceder que otros. Más fácil significa menos cómputo, más directo, lo que resulta en un acceso más rápido. Ahora 'uint32_t' es exactamente de 32 bits en todos los sistemas (si existe), que podría no ser más rápido en comparación con el que tiene, por ejemplo, 64 bits. 'uint_fast32_t' por otro lado ** al menos ** 32 bit, podría ser incluso de 64 bits. – Nawaz
@Destructor: en algunos procesadores, si una variable se almacena en un registro que es más largo, el compilador puede tener que agregar código adicional para cortar cualquier bit adicional. Por ejemplo, si 'uint16_t x;' se almacena en un registro de 32 bits en el ARM7-TDMI, el código 'x ++;' puede necesitar ser evaluado como 'x = ((x + 1) <<16)>> 16);' . En compiladores para esa plataforma, 'uint_fast16_t' probablemente se definiría como sinónimo de' uint32_t' para evitar eso. – supercat
Tenga en cuenta que la versión rápida podría tener más de 32 bits. Mientras que el int rápido encajará muy bien en un registro y estará alineado y similar: pero, usará más memoria. Si tiene grandes matrices de éstos, su programa será más lento debido a más hits de memoria caché y ancho de banda.
No creo que el CPUS moderno se beneficie de fast_int32, ya que generalmente la extensión de signo de 32 a 64 bits puede ocurrir durante la instrucción de carga y la idea de que hay un formato entero 'nativo' más rápido es anticuado .
largo largo es quizás no de 8 bytes, es posible tener un largo largo con 1 byte (en caso de que CHAR_BIT sea al menos 64) o con 3738383 bytes. también uint64_t puede ser 1,2,4 u 8 bytes, CHAR_BIT debe ser 64, 3, 16 u 8 para eso. – 12431234123412341234123