Cuando leo un código, para enteros, usan un montón de tipos diferentes, como size_t, uint32, uint64, etc. ¿Cuál es la motivación o el propósito de hacer esto? ¿Por qué no usar int? relacionado con plataforma-cruz? O bajo nivel relevante.Motivo para usar size_t uint32 uint64 etc.
A veces, el código tiene sentido para mí porque solo quieren 32 bit int o algo así. Pero, ¿qué es size_t? Por favor, ayúdame a aclarar esto.
Estos son para la independencia de la plataforma.
size_t es, por definición, el tipo devuelto por sizeof. Es lo suficientemente grande como para representar el objeto más grande en el sistema de destino.
No hace tantos años, 32 bits hubieran sido suficientes para cualquier plataforma. 64 bits es suficiente hoy. Pero, ¿quién sabe cuántos bits se necesitarán 5, 10 o 50 años a partir de ahora?
Al escribir su código no es importante, es decir, siempre use size_t cuando quiere decir "tamaño de un objeto" - puede escribir código que realmente compilará y ejecutará 5, 10 o 50 años a partir de ahora. O al menos tener una oportunidad de luchar.
Usa los tipos para decir lo que quieres decir. Si por algún motivo necesita una cantidad específica de bits (probablemente solo cuando se trata de un formato definido externamente), use un tipo específico de tamaño. Si desea algo que sea "el tamaño de palabra natural de la máquina", es decir, rápido, use int.
Si está trabajando con una programática como sizeof o strlen, utilice el tipo de datos apropiado para esa interfaz, como size_t.
Y nunca intente asignar un tipo a otro a menos que sea lo suficientemente grande como para mantener el valor por definición.
Para información sobre size_t, consulte la pregunta de desbordamiento de pila: What is size_t in C?
Tienes razón para uint32 y uint64 que sólo están siendo específica sobre el número de bits que les gustaría, y que el compilador debe interpretarlos como unsigned.
El compilador puede interpretar 'uint32_t' y' uint64_t' como cualquiera de varios tipos sin firmar. Por ejemplo, 'uint32_t' puede ser unsigned int o unsigned long (o puede no existir si el sistema no tiene un tipo que es exactamente de 32 bits). El punto es que * sabes * uint32_t es exactamente 32 bits; Todo lo que puede estar seguro de 'unsigned int' es que tiene al menos 16 bits. –
Existen muchas razones posibles para elegir un tipo subyacente para un valor entero. El más obvio es el tamaño del valor máximo posible que puede almacenar: uint32 podrá almacenar un número dos veces más grande que int32, lo que podría ser deseable. int64 podrá almacenar un número mucho más grande que int32 - hasta 2^63 - 1 en lugar de 2^31 - 1.
También hay otros motivos posibles. Si está leyendo directamente datos binarios de alguna fuente (archivo, socket, etc.), es necesario asegurarse de que se interpreten correctamente. Si alguien escribe un uint32 y lo interpreta como int32, es posible que interprete un número positivo muy grande como un número negativo (desbordamiento).
size_t es simplemente un typedef para unsigned int, generalmente de 32 bits, creo.
Para la mayoría de la programación diaria, el tamaño de un entero realmente no importa demasiado. Pero a veces es bueno ser específico. Esto es especialmente útil en programación de bajo nivel o embebida. Otro lugar en el que es útil son las tareas científicas o computacionalmente intensivas en las que puede ser un desperdicio utilizar un int que sea más grande de lo necesario.
La ventaja de size_t es que no está firmado. Por un lado, es agradable usar size_t porque agrega más información acerca de cuál debería ser el argumento (es decir, no negitave). Por otro lado, es menos vinculante vs. unsigned int.
Ser específico (uint64_t, int32_t, etc.) también es muy importante cuando se escribe en un archivo, especialmente si el archivo se va a usar en otras plataformas también, o si debe sobrevivir a un cambio de, por ejemplo, un archivo de 32 bits a un archivo Plataforma o destino de 64 bits –
La motivación para usarlos es porque no se puede confiar en int, short o long tener ningún tamaño particular - un error cometido por muchos programadores demasiadas veces en el pasado. Si observamos no muy atrás en la historia, hubo una transición de procesadores de 16 bits a 32 bits, que rompió gran cantidad de código porque la gente se había basado erróneamente en int siendo 16 bits. El mismo error se cometió a partir de entonces cuando las personas dependían de int para ser de 32 bits, y lo siguen haciendo hasta el día de hoy.
Sin mencionar que los términos int, short y long han sido afectados por diseñadores de idiomas que deciden hacer que signifiquen algo diferente. Un programador de Java que lea C algo ingenuamente esperará que long signifique 64 bits. Estos términos son realmente insignificantes: no especifican nada sobre un tipo, y me encuentro frente a mí cada vez que veo un nuevo idioma que todavía utiliza los términos.
Los tipos int estándar eran una necesidad para que pueda usar el tipo que desea utilizar. Deberían haber desaprobado int, short y long hace décadas.
Los tipos "genéricos" 'int',' short' y 'long', pero también' size_t', etc. deberían ser IMO preferidos para la mayoría de los códigos, donde el tamaño exacto del tipo no es realmente importante. Solo si el tamaño exacto es importante, se deben usar los tipos de "tamaño fijo" como 'uint32_t' o' int64_t'. Tenga en cuenta que están mapeados a los tipos 'int',' long int', etc. que tienen ese tamaño para la implementación. –
¿Pero cómo se puede elegir si se usa 'int',' short' o 'long'? Si el tamaño no es importante, ¿por qué necesitamos 3 palabras clave diferentes que vayan a dar el mismo resultado? Un tipo entero cuyo tamaño no conocemos. –
Si solo necesitas un número pequeño, usa 'short'. Si necesita uno grande, use 'long'. Tenga en cuenta que, por ejemplo, en una plataforma de 16 bits, usar 'int32_t' sería excesivo y bastante ineficiente (probablemente requiera dos registros). En una plataforma de este tipo, 'int' probablemente también sea 16 bits, y mucho más eficiente. –
'puede escribir código que realmente compilará y ejecutará 5, 10 o 50 años a partir de ahora' +1 para el optimismo :-) – Praetorian
Bueno, no en C, pero tengo un código que fue escrito en 1996 y todavía compila y carreras. ¡15 años! –