Usar tipos primitivos sin firmar

Question

La mayoría de las veces representamos conceptos que nunca pueden ser menores que 0.Por ejemplo para declarar longitud, escribimos:

int length;

El nombre expresa bien su propósito pero se le pueden asignar valores negativos.Parece que, en algunas situaciones, puedes representar tu intención más claramente escribiéndola de esta manera:

uint length; 

Algunas desventajas que se me ocurren:

• Los tipos sin firmar (uint, ulong, ushort) no son compatibles con CLS, por lo que no puedes usarlos con otros lenguajes que no lo admitan.
• Las clases .Net usan tipos firmados la mayor parte del tiempo, por lo que debes transmitir

¿Pensamientos?

Answer 1

"Cuando fueres haz lo que vieres."

Si bien en teoría existe una ventaja en el uso de valores sin signo cuando corresponda porque hace que el código sea más expresivo, esto simplemente no se hace en C#.No estoy seguro de por qué los desarrolladores inicialmente no diseñaron las interfaces para manejar uints y hacer que el tipo CLS sea compatible pero ahora el tren ha salido de la estación.

Dado que la coherencia es generalmente importante, recomendaría tomar el camino de C# y usar ints.

Answer 2

Si disminuye un número con signo con un valor de 0, se vuelve negativo y puede comprobarlo fácilmente.Si disminuye un número sin signo con un valor de 0, se desborda y se convierte en el valor máximo para el tipo, algo más difícil de verificar.

Answer 3

Tu segundo punto es el más importante.Generalmente deberías usar int ya que es un "común general" bastante bueno para valores enteros.yo solo usaría uint si es absolutamente necesario la capacidad de contar más que int, pero sin utilizar la memoria extra long requiere (no es mucha más memoria, así que no seas tacaño :-p).

Answer 4

Creo que el uso sutil de uint vs.int causará confusión entre los desarrolladores a menos que esté escrito en las pautas para desarrolladores de la empresa.

Si la longitud, por ejemplo, no puede ser menor que cero, entonces debe expresarse claramente en la lógica empresarial para que los futuros desarrolladores puedan leer el código y conocer la verdadera intención.

Sólo mis 2 centavos.

Answer 5

Señalaré que en C# puedes activar /checked para comprobar si hay desbordamiento o subdesbordamiento aritmético, lo cual de todos modos no es una mala idea.Si el rendimiento es importante en una sección crítica, aún puedes usar unchecked para evitar esto.

Para el código interno (es decir, código al que no se hará referencia en ninguna mansión de interoperabilidad con otros idiomas), voto por usar sin firmar cuando la situación lo amerite, como length variables como se mencionó anteriormente.Esto, junto con la aritmética comprobada, proporciona una red más para los desarrolladores, detectando errores sutiles antes.

Otro punto en el debate entre firmado y no firmado es que algunos programadores usan valores como -1 para indicar errores, cuando de otro modo no tendrían significado.Suscribo la opinión de que cada variable debe tener un solo propósito, pero si a usted (o a sus colegas con los que codifica) les gusta indicar errores de esta manera, dejar las variables firmadas le brinda la flexibilidad de agregar estados de error más adelante.

Answer 6

Tus dos puntos son buenos.Sin embargo, la razón principal para evitarlo es el casting.El casting los hace increíblemente molestos de usar.Intenté usar variables sin firmar una vez, pero tuve que esparcir conversiones absolutamente en todas partes porque todos los métodos del marco usan enteros con signo.Por lo tanto, cada vez que llamas a un método framework, debes realizar una conversión.