Intenta comprender el código de forma correcta previamente a utilizarlo a tu trabajo si tdeseas aportar algo puedes decirlo en los comentarios.
Solución:
uint_least8_t es el tipo más pequeño que tiene al menos 8 bits.
uint_fast8_t es el tipo más rápido que tiene al menos 8 bits.
Puedes ver las diferencias imaginando arquitecturas exóticas. Imagine una arquitectura de 20 bits. Su unsigned int tiene 20 bits (un registro), y su unsigned char tiene 10 bits. Entonces sizeof(int) == 2, pero usando char tipos requiere instrucciones adicionales para cortar los registros por la mitad. Entonces:
uint8_t: no está definido (sin tipo de 8 bits).uint_least8_t: esunsigned char, el tipo más pequeño que tiene al menos 8 bits.uint_fast8_t: esunsigned int, porque en mi arquitectura imaginaria, una variable de medio registro es más lenta que una de registro completo.
uint8_t significa: dame un int sin firmar de exactamente 8 bits.
uint_least8_t significa: dame el tipo más pequeño de int sin firmar que tenga al menos 8 bits. Optimizar para el consumo de memoria.
uint_fast8_t significa: dame un int sin firmar de al menos 8 bits. Elija un tipo más grande si hará que mi programa sea más rápido, debido a consideraciones de alineación. Optimizar para la velocidad.
Además, a diferencia de la llanura int tipos, se garantiza que la versión firmada de los tipos stdint.h anteriores tiene el formato de complemento a 2.
La teoría es algo así como:
uint8_t se requiere que sea exactamente de 8 bits, pero no es necesario que exista. Por lo tanto, debe usarlo cuando confíe en el comportamiento de asignación de módulo-256* de un entero de 8 bits y donde prefiera una falla de compilación a un mal comportamiento en arquitecturas oscuras.
uint_least8_t se requiere que sea el tipo de entero sin signo más pequeño disponible que pueda almacenar al menos 8 bits. Lo usaría cuando desee minimizar el uso de memoria de cosas como arreglos grandes.
uint_fast8_t se supone que es el tipo sin firmar “más rápido” que puede almacenar al menos 8 bits; sin embargo, en realidad no se garantiza que sea el más rápido para una operación determinada en un procesador determinado. Lo usaría en el procesamiento de código que realiza muchas operaciones en el valor.
La práctica es que los tipos “rápido” y “mínimo” no se usan mucho.
Los tipos “menos” solo son realmente útiles si le importa la portabilidad para ocultar arquitecturas con CHAR_BIT != 8 que la mayoría de la gente no.
El problema con los tipos “rápidos” es que “más rápido” es difícil de precisar. Un tipo más pequeño puede significar menos carga en el sistema de memoria/caché, pero usar un tipo más pequeño que el nativo puede requerir instrucciones adicionales. Además, cuál es la mejor puede cambiar entre versiones de arquitectura, pero los implementadores a menudo quieren evitar romper ABI en tales casos.
Al observar algunas implementaciones populares, parece que las definiciones de uint_fastn_t son bastante arbitrarios. glibc parece definirlos como al menos el “tamaño de palabra nativo” del sistema en cuestión, sin tener en cuenta el hecho de que muchos procesadores modernos (especialmente los de 64 bits) tienen soporte específico para operaciones rápidas en elementos más pequeños que su palabra nativa Talla. Aparentemente, IOS los define como equivalentes a los tipos de tamaño fijo. Otras plataformas pueden variar.
En general, si su objetivo es el rendimiento de un código ajustado con pequeños números enteros, debe realizar una evaluación comparativa tu código en las plataformas que le interesan con tipos de diferentes tamaños para ver qué funciona mejor.
* Tenga en cuenta que, lamentablemente, el comportamiento de asignación de módulo 256 no siempre implica aritmética de módulo 256, gracias a la falla de promoción de enteros de C.
Si estás de acuerdo, tienes la habilidad dejar un enunciado acerca de qué le añadirías a este ensayo.