c++ - guide - ¿Dónde dibujar la línea entre size_t y unsigned int?

c++ naming conventions

Question

Esta pregunta ya tiene una respuesta aquí:

• unsigned int vs. size_t 8 respuestas

Actualmente estoy en el proceso de convertir algunos usos de unsigned int a size_t en mi código base que he estado desarrollando a lo largo de los años. Entiendo que la diferencia entre los dos y que, por ejemplo, unsigned int podría ser de 32 bits, mientras que los punteros y size_t podrían ser de 64 bits. Mi pregunta es más acerca de dónde debo usar una y qué tipo de convención usa la gente para elegir entre las dos.

Es bastante claro que la asignación de memoria debe tomar size_t lugar de unsigned int como un argumento, o que las clases de contenedor deben usar size_t para el tamaño y la indexación como en STL. Estos son los casos comunes que se mencionan al leer sobre los beneficios de size_t vs unsigned int . Sin embargo, mientras trabajaba en la conversión de código base, me topé con bastantes casos en áreas grises donde no estoy seguro de cuál usar. Por ejemplo, si el índice de matriz / columna de 4x4 debe ser size_t para mantener la coherencia, independientemente de que el índice esté en el rango [0, 3], o si la resolución de la pantalla / textura debe usar size_t pesar de estar en el rango de unos pocos miles, o en general si es razonable se espera que la cantidad de objetos esté en el rango de decenas que aún debería usar size_t para size_t coherencia.

¿Qué tipo de convenciones de codificación utiliza para seleccionar entre unsigned int y size_t ? ¿Todo lo que representa el tamaño (en bytes u objetos) o el índice debe ser siempre size_t independientemente del rango razonablemente esperado? ¿Existe alguna convención de size_t ampliamente aceptada que se use en bibliotecas bien establecidas que pueda seguir?

Answer 1

Con un puerto de 32 a 64 bits de algún código heredado recientemente en mi mente, la característica clave de size_t en mi mente es que siempre es lo suficientemente grande como para representar todo su espacio de direcciones.

Cualquier otro tipo que pueda nombrar (incluso sin firmar de largo) tiene el potencial de poner un límite artificial en sus estructuras de datos en algún momento en el futuro. size_t (y su primo ptrdiff_t) debe ser la base predeterminada para la construcción de la estructura de datos cuando no se puede definir un límite superior a priori en el dominio.

Answer 2

Creo que es simple, aunque doy la bienvenida a las hondas y flechas.

size_t debe utilizarse si describe algo que tiene un tamaño. (Un conteo. Un número de cosas )

Answer 3

Para mí, la pregunta de si usa un número entero más pequeño que el ancho arquitectónico, es la pregunta de si puede probar que un tamaño más pequeño sea suficiente.

Tomemos, por ejemplo, su Matriz 4x4: ¿Hay alguna razón teórica por la que debe ser 4x4 y no, digamos 5x5 u 8x8? Si existe una razón teórica, no tengo ningún problema con un tipo entero más pequeño. Si no hay ninguno, use size_t u otro tipo que sea al menos igual de ancho.

Mi razonamiento es que los límites fijos (y los tamaños de enteros fijos son solo una forma de introducirlos) generalmente son bichos dormidos. Alguien, algún día probablemente encontrará algún caso de uso extremo donde las suposiciones que hizo para arreglar el límite no se cumplen. Así que quieres evitarlos dondequiera que puedan surgir. Y dado que generalmente no me molesto en hacer una prueba para un tamaño más pequeño (porque no tiene sentido con respecto al rendimiento), por lo general termino usando enteros de tamaño completo.