Übliche arithmetische Konvertierung - ein besseres Regelwerk?

Question

Betrachten Sie den folgenden Code ein:

void f(byte x) {print("byte");} 
void f(short x) {print("short");} 
void f(int x) {print("int");} 

void main() { 
    byte b1, b2; 
    short s1, s2; 

    f(b1 + b2); // byte + byte = int 
    f(s1 + s2); // short + short = int 
} 

In C++, C#, D und Java, die beide Funktion resolve zu den "int" Überlastungen ruft ... ich realisieren bereits dies "in den Spezifikationen", Aber warum sind Sprachen so gestaltet? Ich suche nach einem tieferen Grund.

Für mich macht es Sinn, für das Ergebnis der kleinste Art der Lage sein, alle möglichen Werte der beiden Operanden zu repräsentieren, zum Beispiel:

byte + byte --> byte 
sbyte + sbyte --> sbyte 
byte + sbyte --> short 
short + short --> short 
ushort + ushort --> ushort 
short + ushort --> int 
// etc... 

Dies würde unbequem Code beseitigen wie short s3 = (short)(s1 + s2), wie Auch IMO ist viel intuitiver und leichter zu verstehen.

Ist dies ein übriggebliebenes Vermächtnis aus den Tagen von C, oder gibt es bessere Gründe für das aktuelle Verhalten?

Answer 1

von this MSDN blog post zitiert:

byte b = 32; Byte c = 240; int i = b + c; // was bin ich?

In dieser Fantasy-Welt wäre der Wert von i 16! Warum? Da die beiden Operanden zum + Operator beide Bytes sind, wird also die Summe "b + c" als ein Byte berechnet, was aufgrund von Integer-Überlauf 16 ergibt. (Und, wie ich bereits erwähnt, Integer-Überlauf ist das neue Sicherheitsangriffsvektor.)

ähnlich

int j = -b;

würde aus dem gleichen Grund in j den Wert 224 und nicht -32 ergeben.

Ist das wirklich was du willst?

...

Also egal, wie Sie es drehen, sind Sie ärgerlich Abgüsse einzufügen gehen zu müssen. Kann auch die Sprache haben Fehler auf der Seite der Sicherheit (zwingt Sie , die Casts, wo Sie eingeben, dass Überlauf kein Problem ist) als Fehler auf der Seite der Stille (wo Sie möglicherweise nicht die fehlende beachten wirft bis Ihre Gehaltsabrechnung fragt Sie, warum ihre Bücher nicht am Ende der des Monats summieren.

Es ist auch erwähnenswert, dass das Hinzufügen in diesen Casts nur zusätzliche Eingabe bedeutet, und nichts mehr. Sobald der JIT (oder möglicherweise der statische Compiler selbst) die arithmetische Operation auf eine grundlegende Prozessoranweisung reduziert, ist nichts schlaues passiert - es ist nur, ob die Nummer als int oder byte behandelt wird.

Dies ist eine gute Frage, aber ... überhaupt nicht offensichtlich. Hoffnung, die die Gründe für Sie jetzt klar macht.

Answer 2

Ein besseres Regelwerk IMHO, wenn man vorsieht, dass die Verschiebeoperatoren nur mit konstanten Verschiebungswerten verwendet werden können (verwenden Sie Verschiebefunktionen für variable Verschiebungsbeträge), müssten die Ergebnisse jedes arithmetischen Ausdrucks immer so ausgewertet werden Es wurde mit dem größtmöglichen signierten oder unsignierten Typ verarbeitet, vorausgesetzt, es konnte entweder statisch garantiert werden, dass korrekte Ergebnisse erzielt wurden (leicht knifflige Regeln würden in Fällen gelten, in denen der größte signierte Typ möglicherweise nicht ausreichend ist). Da die angegebenen Shift-Operanden nur Konstanten sein dürfen, könnte man zum Kompilierungszeitpunkt ziemlich einfach feststellen, was der größte bedeutungsvolle Wert eines Operanden sein könnte. Daher sehe ich keinen guten Grund für Compiler, nicht zu schauen, wie das Ergebnis eines Operators verwendet wird bei der Entscheidung über die Implementierung des Betreibers.