Por que os int não assinados não são compatíveis com CLS?

111

Por que os inteiros não assinados não são compatíveis com CLS?

Estou começando a pensar que a especificação de tipo é apenas para desempenho e não para correção.

c# .net unsigned-integer cls-compliant

— doekman
fonte

88

Nem todas as línguas têm o conceito de ints sem sinal. Por exemplo, o VB 6 não tinha conceito de ints não assinados, o que eu suspeito que levou à decisão dos projetistas do VB7 / 7.1 de não implementar também (agora está implementado no VB8).

Citar:

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

O CLS foi projetado para ser grande o suficiente para incluir as construções de linguagem comumente necessárias aos desenvolvedores, mas pequeno o suficiente para que a maioria das linguagens seja capaz de suportá-lo. Além disso, qualquer construção de linguagem que torne impossível verificar rapidamente a segurança de tipo de código foi excluída do CLS para que todas as linguagens compatíveis com CLS possam produzir código verificável se assim escolherem.

Atualização: Eu me perguntei sobre isso há alguns anos e, embora não consiga ver por que um UInt não seria verificável de segurança de tipo, acho que os caras do CLS tiveram que ter um ponto de corte em algum lugar sobre qual seria o mínimo da linha de base número de tipos de valor suportados. Além disso, quando você pensa no longo prazo, em que mais e mais linguagens estão sendo portadas para o CLR, por que forçá-los a implementar ints não assinados para obter conformidade com o CLS se não há absolutamente nenhum conceito, nunca?

— Kev
fonte

@Kevin: Eu só queria saber sobre o assunto. Sua resposta parece lógica. Eu só gosto de pensar sobre o assunto. Acho que é uma pena que tipos como o Pascal não tenham entrado no CLR. Mas seu argumento sobre outras linguagens: isso não impediu o IronPython de usar tipagem fortemente dinâmica (DLR) em um CLR de tipo fortemente estático?

— doekman

@doekman: Embora yes IronPython e IronRuby demonstrem que o CLR pode fornecer uma plataforma na qual você pode construir linguagens tipadas dinamicamente, o objetivo do CLS era fornecer um conjunto de padrões que transcendem a funcionalidade da linguagem e permitem que eles interoperem com sucesso e segurança. Não acho que o que uma linguagem pode fazer em termos de, digamos, adicionar recursos de DL esteja diretamente relacionado ao que deve ser incluído no CLS / CTS.

— Kev

Do meu entendimento, o CLR tem um tipo primitivo inteiro de 32 bits, que tem instruções separadas para adição assinada com verificação de estouro, adição não assinada com verificação de estouro e modo de adição agnóstico de sinal 2 ^ 32, etc .; quando solicitado a converter uma referência de objeto em um primitivo inteiro de 32 bits, o CLR não sabe nem se importa se o código que usa esse número espera que ele seja assinado ou não. Se o compilador acredita que um número é assinado ou não, geralmente afetará as instruções que o compilador gera para operações com ele, mas isso é um problema de linguagem - não de CLR.

— supercat de

23

Parte do problema, eu suspeito, gira em torno do fato de que os tipos inteiros sem sinal em C são obrigados a se comportar como membros de um anel algébrico abstrato em vez de números [significando, por exemplo, que se uma variável inteira sem sinal de 16 bits é igual a zero , diminuí-lo é necessáriopara render 65.535, e se for igual a 65.535 então incrementá-lo é necessário para render zero.] Há momentos em que esse comportamento é extremamente útil, mas os tipos numéricos exibem tal comportamento pode ter ido contra o espírito de algumas linguagens. Eu conjeturaria que a decisão de omitir tipos não assinados provavelmente antecede a decisão de oferecer suporte a contextos numéricos marcados e não marcados. Pessoalmente, gostaria que houvesse tipos inteiros separados para números sem sinal e anéis algébricos; aplicar um operador menos unário a um número não assinado de 32 bits deve produzir um resultado assinado de 64 bits [negar qualquer coisa diferente de zero produziria um número negativo], mas aplicar um menos unário a um tipo de anel deve produzir o inverso aditivo dentro desse anel.

Em qualquer caso, o motivo pelo qual os inteiros não assinados não são compatíveis com CLS é que a Microsoft decidiu que os idiomas não precisavam oferecer suporte a inteiros não assinados para serem considerados "compatíveis com CLS".

— supergato
fonte

Excelente explicação do ponto de vista matemático!

— estranho de

6

Os ints não assinados não ganham muito na vida real, no entanto, ter mais de 1 tipo de int causa dor, portanto, muitos idiomas têm apenas ints unidos.

A conformidade com CLS visa permitir que uma classe seja usada em várias linguagens ...

Lembre-se de que ninguém o torna compatível com CLS.

Você ainda pode usar ints não assinados dentro de um método ou como parâmetros para um método privado , pois é apenas a API pública que o compatível com CLS restringe.

— Ian Ringrose
fonte

16

Eles são essenciais, se você estiver fazendo aritmética bit-a-bit.

— nicodemus13

@ nicodemus13 quando foi a última vez que você viu um sistema de administração de negócios que tinha aritmética bit a bit em seu domínio de problema? (Por exemplo, o tipo de software que os programadores VB.NET escrevem)

— Ian Ringrose

38

Qualquer coisa com uma soma de verificação usará aritmética bit a bit, o que é bastante comum, e parece estranho para mim arrastar todas as outras linguagens para baixo, porque o VB não suportava inteiros sem sinal. O .NET também deve ser genérico, não apenas para gravadores VB de aplicativos LOB. Quando você diz '1 tipo de int', você não acha que ter byte, short, int, long também é uma dor? Não vejo por que assinar é mais difícil.

— nicodemus13

5

Inteiros sem sinal não são compatíveis com CLS porque não são interoperáveis entre certas linguagens.

— Bryan Roth
fonte