Por que o .NET usa int em vez de uint em certas classs?

Eu sempre me deparo com código que usa int para coisas como .Count , etc, mesmo nas classs de estrutura, em vez de uint .

Qual o motivo disso?

UInt32 não é compatível com CLS, portanto, pode não estar disponível em todos os idiomas que têm como alvo a especificação de linguagem comum. Int32 é compatível com CLS e, portanto, é garantido que exista em todos os idiomas.

int, em c, é especificamente definido como o tipo inteiro padrão do processador e, portanto, é considerado o mais rápido para operações numéricas gerais.

Outra razão para usar o int:

Digamos que você tenha um loop como este:

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

(embora você provavelmente não deva fazer assim)

obviamente, se someList.Count fosse 0 e não assinado, você teria um problema.

Se o número é realmente não assinado por sua natureza intrínseca, então eu o declararia como um int não assinado. No entanto, se por acaso eu estiver usando um número (por enquanto) no intervalo positivo, então eu chamaria de int.

As principais razões são:

  • Evita ter que fazer um monte de conversão de tipos, já que a maioria dos methods / funções são escritos para ter um int e não um unsigned int.
  • Elimina possíveis avisos de truncamento.
  • Você, invariavelmente, acaba desejando poder atribuir um valor negativo ao número que você pensava que seria sempre positivo.

São apenas alguns pensamentos rápidos que me vieram à mente.

Eu costumava tentar ser cuidadoso e escolher o próprio unsigned / signed e finalmente percebi que isso não resulta em um benefício positivo. Apenas cria trabalho extra. Então, por que dificultar as coisas misturando e combinando.

UInt32 não é compatível com CLS. http://msdn.microsoft.com/pt-br/library/system.uint32.aspx

Eu acho que ao longo dos anos as pessoas chegaram às conclusões de que usar tipos não assinados não oferece muito benefício. A melhor pergunta é o que você ganha ao fazer o Count a UInt32?

Algumas coisas usam int para que possam retornar -1 como se fosse “null” ou algo parecido. Como um ComboBox retornará -1 para o seu SelectedIndex, se ele não tiver nenhum item selecionado.

Os tipos não assinados só se comportam como números inteiros se a sum ou o produto de um valor assinado e não assinado for um tipo assinado grande o suficiente para conter um operando e se a diferença entre dois valores não assinados for um valor assinado suficientemente grande para conter qualquer resultado. Assim, o código que faz uso significativo do UInt32 precisará freqüentemente computar valores como Int64 . Operações em tipos inteiros assinados podem falhar ao operar como números inteiros quando os operandos são excessivamente grandes, mas eles se comportarão sensivelmente quando operandos forem pequenos. Operações em argumentos não-formatados de tipos não assinados apresentam problemas mesmo quando operandos são pequenos. Dado UInt32 x; por exemplo, a desigualdade x-1 < x falhará para x==0 se o tipo de resultado for UInt32 e a desigualdade x<=0 || x-1>=0 x<=0 || x-1>=0 falhará para valores x grandes se o tipo de resultado for Int32 . Somente se a operação for executada no tipo Int64 duas desigualdades poderão ser mantidas.

Embora às vezes seja útil definir o comportamento do tipo não sinalizado de formas que diferem da aritmética de número inteiro, os valores que representam coisas como contagens geralmente usam tipos que se comportarão como números inteiros - algo que tipos não assinados geralmente não fazem a menos que eles re menor que o tipo inteiro básico.

Algumas bibliotecas antigas e até mesmo InStr usam números negativos para significar casos especiais. Eu acredito que seja por sua preguiça ou por valores especiais negativos.