¿Por qué los unsigned int no son CLS?

Question

¿Por qué los enteros sin signo no cumplen con CLS?

Estoy empezando a pensar que la especificación de tipo es solo por el rendimiento y no por la corrección.

Answer 1

No todos los idiomas tienen el concepto de ints sin firmar. Por ejemplo, VB 6 no tenía ningún concepto de entradas sin firmar, que sospecho impulsó la decisión de los diseñadores de VB7/7.1 de no implementar también (se implementa ahora en VB8).

Para citar:

http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

El CLS fue diseñado para ser lo suficientemente grande como para incluir el idioma construcciones que se usan comúnmente por los desarrolladores, pero lo suficientemente que la mayoría de las lenguas son capaces de apoyar a los pequeños eso. Además, cualquier construcción de lenguaje que imposibilite verificar rápidamente el tipo de seguridad del código se excluyó del CLS para que todos los lenguajes compatibles con CLS puedan producir código verificable si así lo desean.

Actualización: Me pregunto acerca de este hace unos años, y aunque no puedo ver por qué un UInt no sería la seguridad de tipos verificable, supongo que los chicos CLS tenía que tener un punto de corte en alguna parte que se cuál sería la cantidad mínima de referencia de los tipos de valor admitidos. Además, cuando piense en un plazo más largo en el que se transfieren cada vez más idiomas al CLR, ¿por qué obligarlos a implementar ints sin firmar para obtener el cumplimiento de CLS si no existe absolutamente ningún concepto?

Answer 2

Los enteros sin signo no son compatibles con CLS porque no son interoperables entre ciertos idiomas.

Answer 3

Las int sin firmar no te permiten tanto en la vida real, sin embargo, tener más de 1 tipo de int te da dolor, por lo que muchos idiomas solo tienen sintetizadores.

compatible con CLS tiene por objeto permitir una clase que se hizo uso de una gran cantidad de idiomas de ...

recordar que nadie te hace ser compatible con CLS.

Puede seguir utilizando enteros sin signo dentro un método, o como parms a un método privado, ya que es sólo la API pública que restringe CLS compatibles.

Answer 4

Parte del problema, sospecho, gira en torno al hecho de que los tipos enteros sin signo en C deben comportarse como miembros de un anillo algebraico abstracto en lugar de como números [lo que significa, por ejemplo, que si un 16 bits sin signo la variable entera es igual a cero, decrementando que es requerido para obtener 65.535, y si es igual a 65.535, entonces incrementarlo es necesario para producir cero.] Hay momentos en que tal comportamiento es extremadamente útil, pero los tipos numéricos muestran que tal comportamiento puede haber desaparecido contra el espíritu de algunos idiomas. Conjeturo que la decisión de omitir los tipos sin firmar probablemente sea anterior a la decisión de admitir contextos numéricos comprobados y no verificados. Personalmente, desearía que hubiese habido tipos enteros separados para números sin firmar y anillos algebraicos; aplicar un operador unario negativo al número de 32 bits sin signo debería producir un resultado firmado de 64 bits [anular cualquier cosa que no sea cero arrojaría un número negativo] pero aplicar un menos unario a un tipo de anillo debería arrojar la inversa aditiva dentro de ese anillo.

En cualquier caso, los enteros sin signo de la razón no son compatibles con CLS es que Microsoft decidió que las lenguas no tienen que apoyar enteros sin signo con el fin de ser considerado "CLS compatible".