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

111

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

doekman
fuente

Respuestas:

88

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?

Kev
fuente
@Kevin: Solo me preguntaba sobre el tema. Tu respuesta parece lógica. Solo me gusta pensar en el tema. Creo que es una lástima que los tipos como Pascal no hayan llegado al CLR. Pero su argumento sobre otros lenguajes: ¿eso no impidió que IronPython usara tipado fuertemente dinámico (DLR) en un CLR fuertemente estático?
doekman
@doekman: Si bien IronPython e IronRuby demuestran que CLR puede proporcionar una plataforma en la que se pueden construir lenguajes tipados dinámicamente, el objetivo de CLS era proporcionar un conjunto de estándares que trascienden la funcionalidad del lenguaje y les permiten interoperar de manera exitosa y segura. No creo que lo que pueda hacer un lenguaje en términos de agregar características de DL esté directamente relacionado con lo que debería incluirse en CLS / CTS.
Kev
Según tengo entendido, CLR tiene un tipo primitivo entero de 32 bits, que tiene instrucciones separadas para la suma con signo con verificación de desbordamiento, la adición sin firmar con verificación de desbordamiento y la adición agnóstica de signo mod 2 ^ 32, etc .; cuando se le pide que convierta una referencia de objeto en una primitiva de entero de 32 bits, el CLR no sabe ni le importa si el código que usa ese número espera que esté firmado o sin firmar. Si el compilador cree que un número está firmado o no, generalmente afectará las instrucciones que genera el compilador para las operaciones con él, pero eso es un problema de lenguaje, no de CLR.
supercat
23

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

Super gato
fuente
¡Excelente explicación desde la perspectiva matemática!
dizarter
6

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.

Ian Ringrose
fuente
16
Son bastante esenciales, si está haciendo aritmética de bits.
nicodemus13
@ nicodemus13 ¿cuándo fue la última vez que vio un sistema de administración empresarial que tenía aritmética de bits en su dominio de problemas? (Por ejemplo, el tipo de software que escriben los programadores de VB.NET)
Ian Ringrose
38
Cualquier cosa con una suma de comprobación usará aritmética bit a bit, eso es bastante común, y me parece extraño arrastrar todos los demás idiomas hacia abajo, porque VB no admitía enteros sin signo. .NET también está destinado a ser genérico, no solo para los escritores de VB de aplicaciones LOB. Cuando dices '1 tipo de int', ¿no crees que tener byte, short, int, long también sea un dolor? No veo por qué firmar es más incómodo.
nicodemus13
5

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

Bryan Roth
fuente