c# - significado - usando uint vs int

para que sirve el int (11)

1) Mal hábito. Seriamente. Incluso en C / C ++.

Piensa en lo común for patrón:

for( int i=0; i<3; i++ ) foo(i);

No hay absolutamente ninguna razón para usar un número entero allí. Nunca tendrás valores negativos. Pero casi todos harán un bucle simple de esa manera, incluso si contiene (al menos) otros dos errores de "estilo".

2) int se percibe como el tipo nativo de la máquina.

He observado por un tiempo que los programadores de C # tienden a usar int en todas partes, y rara vez recurren a uint. Pero nunca descubrí una respuesta satisfactoria sobre por qué.

Si su objetivo es la interoperabilidad, uint no debería aparecer en las API públicas porque no todos los lenguajes CLI admiten enteros sin signo. Pero eso no explica por qué int es tan frecuente, incluso en las clases internas. Sospecho que esta es la razón por la cual uint se usa con moderación en el BCL.

En C ++, si tiene un número entero para el cual los valores negativos no tienen sentido, usted elige un entero sin signo.

Esto claramente significa que los números negativos no son permitidos o esperados, y el compilador hará una cierta verificación por usted. También sospecho que en el caso de los índices de matriz, el JIT puede soltar fácilmente la verificación de límites inferiores.

Sin embargo, al mezclar int y tipos de unidades, se necesitarán cuidados adicionales y moldes.

¿Debería usarse más? ¿Por qué?

Algunos idiomas (por ejemplo, muchas versiones de Pascal) consideran que los tipos sin signo representan cantidades numéricas; una operación entre un tipo sin signo y un tipo firmado del mismo tamaño generalmente se realizará como si los operandos se promocionaran al siguiente tipo más grande (en algunos idiomas, el tipo más grande no tiene equivalente sin signo, por lo que tal promoción siempre será posible) )

Otros lenguajes (por ejemplo, C) consideran los tipos sin signo de N bits como un grupo que se ajusta al módulo 2 ^ N. Tenga en cuenta que restar N de un miembro de dicho grupo no representa la resta numérica, sino que cede el miembro del grupo que, cuando se agrega N, arrojaría el original. Podría decirse que ciertas operaciones que involucran mezclas de valores firmados y no firmados realmente no tienen sentido y quizás deberían haber sido prohibidas, pero incluso el código que es descuidado con sus especificaciones de cosas como literales numéricos generalmente funcionará, y se ha escrito un código que mezcla firmado y tipos sin firmar y, a pesar de ser descuidado, funciona, que la especificación no es apta para cambiar pronto.

Es mucho más fácil trabajar exclusivamente con tipos firmados que resolver todas las complejidades de las interacciones entre tipos firmados y no firmados. Los tipos sin signo son útiles al descomponer números grandes de piezas más pequeñas (por ejemplo, para la serialización) o para reconstituir tales números, pero en general es mejor simplemente usar números con signo para cosas que en realidad representan cantidades

Creo que es solo pereza. C # es intrínsecamente una opción para el desarrollo en computadoras de escritorio y otras máquinas con relativamente muchos recursos.

C y C ++, sin embargo, tienen profundas raíces en sistemas antiguos y sistemas integrados donde la memoria es escasa, por lo que los programadores se utilizan para pensar cuidadosamente qué tipo de datos usar. Los programadores de C # son flojos, y dado que hay recursos suficientes en general, nadie realmente optimiza el uso de la memoria (en general, no siempre por supuesto). Si un byte fuera suficiente, muchos programadores de C #, incluyéndome a mí, simplemente usan int para simplificar. Además, muchas funciones API aceptan entradas, por lo que previene el lanzamiento.

Estoy de acuerdo en que elegir el tipo de datos correcto es una buena práctica, pero creo que la principal motivación es la pereza.

Finalmente, elegir un número entero es más matemáticamente correcto. Las entradas sin firmar no existen en matemáticas (solo números naturales). Y dado que la mayoría de los programadores tienen una formación matemática, usar un número entero es más natural.

Creo que una gran parte de la razón es que cuando C apareció por primera vez, la mayoría de los ejemplos se usaban para abreviar la brevedad. Nos regocijamos por no tener que escribir integer como lo hicimos con Fortran y Pascal, y en esos días los usábamos rutinariamente para cosas mundanas como índices de matriz y contadores de bucle. Los enteros sin signo eran casos especiales para números grandes que necesitaban ese último bit adicional. Creo que es una progresión natural que los hábitos C continúen en C # y otros nuevos lenguajes como Python.

He creado un contenedor Direct3D 10 en C # y necesito usar uint si quiero crear buffers de vértices muy grandes. Los búferes grandes en la tarjeta de video no se pueden representar con un int firmado.

UINT es muy útil y es tonto decir lo contrario. Si alguien piensa simplemente porque nunca han necesitado usar uint nadie más lo hará, estás equivocado.

Normalmente int será suficiente. Si puede satisfacer todas las condiciones siguientes, puede usar uint :

No es para una API pública (ya que uint no es compatible con CLS).
No necesitas números negativos
Usted (podría) necesitar el rango adicional.
No lo estás usando en comparación con < 0 , ya que eso nunca es true .
No lo está usando en una comparación con >= 0 , ya que eso nunca es false .

El último requisito a menudo se olvida y presentará errores:

static void Main(string[] args) { if (args.Length == 0) return; uint last = (uint)(args.Length - 1); // This will eventually throw an IndexOutOfRangeException: for (uint i = last; i >= 0; i--) { Console.WriteLine(args[i]); } }

Prefiero uint a int menos que un número negativo esté realmente en el rango de valores aceptables. En particular, aceptar un param int pero lanzar una ArgumentException si el número es menor que cero es simplemente una tontería: ¡use un uint !

Estoy de acuerdo con que uint está infrautilizado, y animo a todos a usarlo más.

Programo en una capa de aplicación de nivel inferior donde los ints rara vez superan los 100, por lo que los valores negativos no son un problema (por ejemplo, para i <myname.length () tipo de cosas) es solo un antiguo hábito de C, y más corto para escribir como se mencionó anteriormente. Sin embargo, en algunos casos, cuando se hace interfaz con hardware en el que estoy tratando con indicadores de eventos de dispositivos, la uint es importante en los casos en que un indicador puede usar el bit más a la izquierda (el más alto).

Honestamente, para el 99.9% de mi trabajo podría usar usualmente el estilo corto, pero int, ya sabes, suena mucho mejor que usualmente corto.

Sé que este es probablemente un hilo viejo, pero quería dar algunas aclaraciones.

Tomemos un int8, puede almacenar -128 a 127 y usa 1 byte, que es un total de 127 números positivos.
Cuando usa un int8, uno de los bits se usa para los números negativos -128.
Cuando usas un Uint8, le das los números negativos al positivo, así que esto te permite usar 255 números positivos con la misma cantidad de almacenamiento de 1 byte.
El único inconveniente es que ahora ha perdido la capacidad de usar valores negativos.
Otro problema con esto no son todos los lenguajes de programación y las bases de datos lo soportan.
La única razón por la que usaría esto en mi opinión es cuando necesita ser eficiente en la programación de juegos y tiene que almacenar números grandes no negativos. Es por eso que no muchos programas lo usan.

La razón principal es que el almacenamiento no es un problema y no puede usarlo de manera flexible con otro software, complementos, base de datos o Api. También, por ejemplo, un banco necesitaría números negativos para almacenar dinero, etc.

Espero que esto ayude a alguien.

Su observación de por qué uint no se usa en el BCL es la razón principal, sospecho.

UInt32 no cumple con CLS, lo que significa que es totalmente inapropiado para su uso en API públicas. Si va a utilizar uint en su API privada, esto significará realizar conversiones a otros tipos, y generalmente es más fácil y seguro mantener el mismo tipo.

También sospecho que esto no es tan común en el desarrollo de C #, incluso cuando C # es el único lenguaje utilizado, principalmente porque no es común en el BCL. Los desarrolladores, en general, intentan (afortunadamente) imitar el estilo del marco en el que están construyendo: en el caso de C #, esto significa tratar de hacer que sus API, públicas e internas, se parezcan tanto a .NET Framework BCL como sea posible. Esto significaría usar uint con moderación.

int es más corto de escribir que uint .