¿Por qué los tipos de CLR sin firmar son tan difíciles de usar en C#?

Question

Vengo de un fondo en su mayoría C/C++ antes de comenzar a usar C#. Una de las cosas que hice con mi primer proyecto en C# fue hacer una clase como esta

class Element{ 
    public uint Size; 
    public ulong BigThing; 
} 

entonces yo estaba mortificado por el hecho de que esto requiere de calidad:

int x=MyElement.Size; 

al igual que

int x=5; 
uint total=MyElement.Size+x; 

¿Por qué los diseñadores de idiomas decidieron hacer que los tipos de entero con signo y sin signo no se moldeen implícitamente? ¿Y por qué los tipos sin firmar no se usan más en toda la biblioteca .Net? Por ejemplo, String.Length nunca puede ser negativo, sin embargo, es un número entero con signo.

Answer 1

¿Por qué los diseñadores de idiomas decidieron convertir implícitamente los tipos de entero con signo y sin signo ?

Porque eso podría perder datos o arrojar cualquier excepción, ninguno de los cuales es generalmente algo bueno que permitir implícitamente. (La conversión implícita de largo para duplicar puede perder datos demasiado, es cierto, pero de una manera diferente.)

Y por qué son los tipos sin signo que no se usan más en toda la biblioteca .Net

tipos sin signo no son compatibles con CLS, no todos los lenguajes .NET siempre han sido compatibles. Por ejemplo, Visual Basic no tenía soporte "nativo" para tipos de datos sin signo en .NET 1.0 y 1.1; fue agregado al lenguaje para 2.0. (Todavía podría usarlos, pero no eran parte del lenguaje en sí; no podía usar los operadores aritméticos normales, por ejemplo).

Answer 2

Porque convertir implícitamente un entero sin signo de 3B en un entero con signo va hacer estallar.

Sin firmar tiene el doble del valor máximo de firmado. Es la misma razón por la que no puedes lanzar un anhelado int.

Answer 3

Junto con la respuesta de Jon, el hecho de que un número sin firmar no pueda ser negativo no significa que no sea más grande que uno firmado. uint es 0 a 4,294,967,295 pero int es -2,147,483,648 a 2,147,483,647. Mucho espacio por encima de int como máximo de pérdida.

Answer 4

En el segundo recuento: porque querían que el CLR fuera compatible con los idiomas que no tienen tipos de datos sin signo (léase: VB.NET).

Answer 5

entonces yo estaba mortificado por el hecho de que esto requiere de calidad:

int x=MyElement.Size; 

Pero se contradice aquí. Si realmente (realmente) necesita que el Tamaño no esté firmado en lugar de asignarlo a (firmado) x es un error. Un profundo error en tu código.

Por ejemplo Cadena.Longitud nunca puede ser negativo, sin embargo, es un entero con signo

Pero String.IndexOf puede devolver un número negativo, y sería muy conveniente si los valores y String.length índice donde de diferentes tipos.

Y si bien en teoría habría un mérito en un String.Length sin firmar (4 GB de límite), en la práctica incluso los 2 GB actuales son lo suficientemente grandes (porque las cadenas de esa longitud son raras e impracticables).

Así que la verdadera respuesta es: ¿Por qué usar unsigned en primer lugar?