¿Por qué .NET usa int en lugar de uint en ciertas clases?

Siempre me encuentro con código que usa int para cosas como .Count , etc., incluso en las clases de framework, en lugar de uint .

¿Cuál es el motivo de esto?

UInt32 no es compatible con CLS, por lo que podría no estar disponible en todos los idiomas que se dirigen a la especificación de lenguaje común. Int32 cumple con CLS y, por lo tanto, está garantizado que existe en todos los idiomas.

int, in c, se define específicamente como el tipo entero predeterminado del procesador y, por lo tanto, se considera que es el más rápido para las operaciones numéricas generales.

Otra razón para usar int:

Digamos que tiene un bucle for como este:

 for (i = 0; i <= someList.Count - 1; i++) { // Stuff } 

(aunque probablemente no deberías hacerlo de esa manera)

Obviamente, si someList.Count fuera 0 y no estuviera firmado, tendrías un problema.

Si el número no está realmente firmado por su naturaleza intrínseca, entonces lo declararía como un int sin firmar. Sin embargo, si resulta que estoy usando un número (por el momento) en el rango positivo, entonces lo llamaría int.

Las principales razones son que:

  • Evita tener que hacer mucho fundido de tipos ya que la mayoría de los métodos / funciones están escritos para tomar un int y no un int sin signo.
  • Elimina posibles advertencias de truncamiento.
  • Invariablemente terminas deseando poder asignar un valor negativo al número que originalmente pensabas que sería siempre positivo.

Son solo unos pocos pensamientos rápidos que me vinieron a la mente.

Solía ​​tratar de ser muy cuidadoso y elegir el apropiado sin firmar / firmado y finalmente me di cuenta de que realmente no resulta en un beneficio positivo. Simplemente crea trabajo extra. Entonces, ¿por qué complicar las cosas mezclando y combinando?

UInt32 no cumple con CLS. http://msdn.microsoft.com/en-us/library/system.uint32.aspx

Creo que a lo largo de los años la gente ha llegado a la conclusión de que el uso de tipos sin firmar realmente no ofrece tantos beneficios. La mejor pregunta es: ¿qué ganarías haciendo Count a UInt32?

Algunas cosas usan int para que puedan devolver -1 como si fuera “nulo” o algo así. Al igual que un ComboBox, devolverá -1 por su SelectedIndex si no tiene ningún elemento seleccionado.

Los tipos sin firmar solo se comportan como números enteros si la sum o producto de un valor firmado y sin firmar será lo suficientemente grande para contener cualquiera de los dos operandos, y si la diferencia entre dos valores sin firmar es un valor firmado suficientemente grande para contener cualquier resultado. Por lo tanto, el código que hace un uso significativo de UInt32 con frecuencia necesitará calcular valores como Int64 . Las operaciones en tipos enteros con signo pueden no funcionar como números enteros cuando los operandos son demasiado grandes, pero se comportarán con sensatez cuando los operandos son pequeños. Las operaciones en argumentos no promocionados de tipos sin firmar presentan problemas incluso cuando los operandos son pequeños. Dado UInt32 x; por ejemplo, la desigualdad x-1 < x fallará para x==0 si el tipo de resultado es UInt32 y la desigualdad x<=0 || x-1>=0 x<=0 || x-1>=0 fallará para valores x grandes si el tipo de resultado es Int32 . Solo si la operación se realiza en el tipo Int64 pueden Int64 ambas desigualdades.

Si bien a veces es útil definir el comportamiento de tipo sin signo de manera diferente a la aritmética de números enteros, los valores que representan cosas como los recuentos generalmente deben usar tipos que se comporten como números enteros; por lo general, los tipos sin signo no funcionan a menos que re más pequeño que el tipo entero básico.

Algunas bibliotecas antiguas e incluso InStr usan números negativos para significar casos especiales. Creo que o bien es pereza o que hay valores especiales negativos.