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

Question

¿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.

Answer 1

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 implementarlo 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 como para incluir las construcciones de idiomas que los desarrolladores necesitan comúnmente, pero lo suficientemente pequeños como para que la mayoría de los idiomas puedan apoyarlo.Además, cualquier construcción de lenguaje que haga imposible verificar rápidamente el tipo de seguridad del código se excluyó del CLS para que todos los idiomas que cumplan con el CLS puedan producir un código verificable si eligen hacerlo.

Actualizar:Me pregunté sobre esto hace algunos años, y aunque no veo por qué un UInt no sería verificable con 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 número mínimo de referencia de tipos de valores admitidos.Además, cuando piensa en el largo plazo, donde cada vez se migran más lenguajes al CLR, ¿por qué obligarlos a implementar entradas sin firmar para lograr el cumplimiento de CLS si nunca existe absolutamente ningún concepto?

Answer 2

Sospecho que parte del problema 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 una variable entera sin signo de 16 bits es igual a cero , decrementando es requerido para producir 65,535, y si es igual a 65,535 entonces es necesario incrementarlo para producir cero.] Hay ocasiones en las que este comportamiento es extremadamente útil, pero los tipos numéricos exhiben tal comportamiento que puede haber ido en contra del espíritu de algunos lenguajes.Yo conjeturaría que la decisión de omitir los tipos sin firmar probablemente sea anterior a la decisión de admitir contextos numéricos tanto marcados como no marcados.Personalmente, desearía que hubiera tipos 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 de 64 bits con signo [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 signo no son compatibles con CLS es que Microsoft decidió que los idiomas no tenían que admitir enteros sin signo para ser considerados "compatibles con CLS".

Answer 3

Los int sin signo no te aportan mucho 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 chamuscados.

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.

Todavía puedes usar entradas sin firmar dentro un método, o como parámetros de un privado método, ya que solo la API pública es la que restringe el cumplimiento de CLS.

Answer 4

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