¿Por qué los int sin firmar no cumplen con CLS?

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

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

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

Citar:

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

El CLS fue diseñado para ser lo suficientemente grande para incluir las construcciones de lenguaje que los desarrolladores necesitan comúnmente, pero lo suficientemente pequeño como para que la mayoría de los lenguajes puedan admitirlo. Además, se excluyó del CLS cualquier construcción de lenguaje que hiciera imposible verificar rápidamente el tipo de código de seguridad para que todos los lenguajes compatibles con CLS puedan producir código verificable si así lo desean.

Actualización: me pregunté sobre esto hace algunos años, y aunque no puedo ver por qué un UInt no sería verificable de seguridad de tipo, supongo que los chicos de CLS tenían que tener un punto de corte en algún lugar en cuanto a cuál sería el mínimo de referencia número de tipos de valor admitidos. Además, cuando piensa en un plazo más largo, en el que cada vez se transfieren más idiomas a CLR, ¿por qué obligarlos a implementar entradas sin firmar para obtener el cumplimiento de CLS si no hay absolutamente ningún concepto, nunca?

Sospecho que parte del problema gira en torno al hecho de que los tipos de 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 una variable de entero de 16 bits sin signo es igual a cero , decrementando es requierepara producir 65.535, y si es igual a 65.535, entonces se requiere incrementarlo para producir cero.] Hay momentos en que tal comportamiento es extremadamente útil, pero los tipos numéricos exhiben tal comportamiento pueden haber ido en contra del espíritu de algunos lenguajes. Yo conjeturaría que la decisión de omitir tipos sin firmar probablemente sea anterior a la decisión de admitir contextos numéricos marcados y no marcados. Personalmente, desearía que hubiera tipos de enteros separados para números sin signo y anillos algebraicos; aplicar un operador menos unario a un número de 32 bits sin signo debería producir un resultado con signo de 64 bits [negar cualquier cosa que no sea cero produciría un número negativo] pero aplicar un menos unario a un tipo de anillo debería producir el inverso aditivo dentro de ese anillo.

En cualquier caso, la razón por la que los enteros sin firmar no cumplen con CLS es que Microsoft decidió que los idiomas no tenían que admitir enteros sin firmar para ser considerados "compatibles con CLS".

Los int sin firmar no te benefician tanto en la vida real, sin embargo, tener más de un tipo de int te causa dolor, por lo que muchos idiomas solo tienen int cantados.

La compatibilidad con CLS tiene como objetivo permitir que una clase se utilice en muchos idiomas ...

Recuerde que nadie le obliga a cumplir con CLS.

Aún puede usar entradas sin firmar dentro de un método, o como parms para un método privado , ya que solo la API pública restringe el cumplimiento de CLS.

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