Perché gli int senza segno non sono conformi a CLS?

111

Perché gli interi senza segno non sono conformi a CLS?

Sto iniziando a pensare che la specifica del tipo sia solo per le prestazioni e non per la correttezza.

c# .net unsigned-integer cls-compliant

— doekman
fonte

88

Non tutte le lingue hanno il concetto di int senza segno. Ad esempio VB 6 non aveva il concetto di int senza segno che sospetto abbia guidato la decisione dei progettisti di VB7 / 7.1 di non implementarlo (è implementato ora in VB8).

Per citare:

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

Il CLS è stato progettato per essere abbastanza grande da includere i costrutti del linguaggio comunemente necessari agli sviluppatori, ma abbastanza piccolo da essere supportato dalla maggior parte dei linguaggi. Inoltre, qualsiasi costrutto di linguaggio che renda impossibile verificare rapidamente l'indipendenza dai tipi del codice è stato escluso dal CLS in modo che tutti i linguaggi conformi a CLS possano produrre codice verificabile se scelgono di farlo.

Aggiornamento: mi sono chiesto di questo alcuni anni fa, e anche se non riesco a capire perché un UInt non sarebbe verificabile sulla sicurezza dei tipi, immagino che i ragazzi di CLS dovessero avere un punto di interruzione da qualche parte su quale sarebbe il minimo di base numero di tipi di valore supportati. Inoltre, quando si pensa al lungo termine in cui sempre più lingue vengono portate nel CLR, perché costringerle a implementare int non firmati per ottenere la conformità CLS se non esiste assolutamente alcun concetto, mai?

— kev
fonte

@ Kevin: mi chiedevo solo l'argomento. La tua risposta sembra logica. Mi piace solo pensare all'argomento. Penso che sia un peccato che i tipi simili a Pascal non siano entrati nel CLR. Ma la tua argomentazione sugli altri linguaggi: questo non ha impedito a IronPython di utilizzare la tipizzazione fortemente dinamica (DLR) in un CLR fortemente statico?

— portiere

@doekman: anche se sì, IronPython e IronRuby dimostrano che CLR può fornire una piattaforma su cui creare linguaggi tipizzati dinamicamente, l'obiettivo del CLS era fornire una serie di standard che trascendessero la funzionalità del linguaggio e consentissero loro di interagire con successo e in sicurezza. Non penso che cosa può fare una lingua in termini di dire che l'aggiunta di funzionalità DL è direttamente correlata a ciò che dovrebbe essere contenuto in CLS / CTS.

— Kev

Dalla mia comprensione, il CLR ha un tipo primitivo intero a 32 bit, che ha istruzioni separate per l'aggiunta con segno con controllo dell'overflow, aggiunta senza segno con controllo dell'overflow e aggiunta indipendente dal segno mod 2 ^ 32, ecc .; quando viene chiesto di convertire un riferimento a un oggetto in una primitiva intera a 32 bit, il CLR non sa né si preoccupa se il codice che utilizza quel numero si aspetta che sia firmato o non firmato. Il fatto che il compilatore ritenga che un numero sia firmato o non firmato influirà generalmente sulle istruzioni che il compilatore genera per le operazioni con esso, ma questo è un problema di linguaggio, non CLR.

— supercat

23

Parte del problema, sospetto, ruota attorno al fatto che i tipi interi senza segno in C devono comportarsi come membri di un anello algebrico astratto piuttosto che come numeri [il che significa, ad esempio, che se una variabile intera senza segno a 16 bit è uguale a zero , diminuendolo è necessarioper restituire 65.535, e se è uguale a 65.535, l'incremento è necessario per restituire zero.] Ci sono momenti in cui tale comportamento è estremamente utile, ma i tipi numerici mostrano tale comportamento potrebbero essere andati contro lo spirito di alcuni linguaggi. Suppongo che la decisione di omettere i tipi non firmati probabilmente precede la decisione di supportare contesti numerici controllati e non controllati. Personalmente, vorrei che ci fossero stati tipi interi separati per numeri senza segno e anelli algebrici; l'applicazione di un operatore meno unario a un numero a 32 bit senza segno dovrebbe produrre un risultato con segno a 64 bit [negare qualsiasi cosa diversa da zero produrrebbe un numero negativo] ma applicare un meno unario a un tipo di anello dovrebbe produrre l'inverso additivo all'interno di quell'anello.

In ogni caso, il motivo per cui gli interi senza segno non sono conformi a CLS è che Microsoft ha deciso che le lingue non dovevano supportare interi senza segno per essere considerate "compatibili con CLS".

— Supercat
fonte

Ottima spiegazione dal punto di vista matematico!

— dizarter

6

Gli int senza segno non ti fanno guadagnare molto nella vita reale, tuttavia avere più di un tipo di int ti dà dolore, quindi molte lingue hanno solo int cantati.

La conformità a CLS ha lo scopo di consentire l'utilizzo di una classe da molte lingue ...

Ricorda che nessuno ti rende conforme a CLS.

È comunque possibile utilizzare int senza segno all'interno di un metodo o come parametri per un metodo privato , poiché è solo l'API pubblica che limita la conformità a CLS.

— Ian Ringrose
fonte

16

Sono praticamente essenziali, se stai facendo aritmetica un po 'saggia.

— nicodemus13

@ nicodemus13 quando è stata l'ultima volta che hai visto un sistema di amministrazione aziendale che aveva un'aritmetica bit-saggia nel suo dominio problematico? (Es. Il tipo di software che scrivono i programmatori di VB.NET)

— Ian Ringrose

38

Qualunque cosa con un checksum utilizzerà l'aritmetica bit-wise, è abbastanza comune, e mi sembra strano trascinare verso il basso ogni altra lingua, perché VB non supportava interi senza segno. .NET è pensato anche per essere generico, non solo per i VB-writer di app LOB. Quando dici "1 tipo di int", non pensi che avere byte, short, int, long sia anche un problema? Non vedo bene perché la firma sia più imbarazzante.

— nicodemus13

5

Gli interi senza segno non sono conformi a CLS perché non sono interoperabili tra determinati linguaggi.

— Bryan Roth
fonte