Warum muss in C und C++ vor arithmetischen Operationen ein short in ein int umgewandelt werden?

Aus den Antworten, die ich auf diese Frage erhalten habe, geht hervor, dass C++ diese Anforderung für die Konvertierung von geerbt hat short hinein int bei der Durchführung von arithmetischen Operationen von C. Darf ich Ihnen den Kopf darüber zerbrechen warum wurde dies überhaupt erst in C eingeführt? Warum führen Sie diese Operationen nicht einfach so durch short?

Zum Beispiel (entnommen aus dyps Vorschlag in den Kommentaren):

short s = 1, t = 2 ;
auto  x = s + t ;

x wird Typ haben int.

Betrachten wir die Begründung für International Standard – Programmiersprachen – C im Abschnitt 6.3.1.8 Übliche arithmetische Umrechnungen es sagt (Hervorhebung von mir für die Zukunft):

Die Regeln im Standard für diese Konvertierungen sind leichte Modifikationen von denen in K&R: Die Modifikationen berücksichtigen die hinzugefügten Typen und die werterhaltenden Regeln. Es wurde eine explizite Lizenz hinzugefügt, um Berechnungen in einem „breiteren“ Typ als unbedingt erforderlich durchzuführen, da dies manchmal zu kleinerem und schnellerem Code führen kann, ganz zu schweigen von der häufigeren richtigen Antwort. Berechnungen können auch in einer “engeren” Art durch die Als-ob-Regel durchgeführt werden, solange das gleiche Endergebnis erhalten wird. Explizites Casting kann immer verwendet werden, um einen Wert in einem gewünschten Typ zu erhalten

Abschnitt 6.3.1.8 von dem Entwurf des C99-Standards deckt die ab Übliche arithmetische Umrechnungen die auf Operanden von arithmetischen Ausdrücken zum Beispiel Abschnitt angewendet wird 6.5.6 Additive Operatoren sagt:

Wenn beide Operanden vom arithmetischen Typ sind, wird die übliche arithmetische Umrechnungen werden an ihnen durchgeführt.

Wir finden ähnlichen Text in Abschnitt 6.5.5 Multiplikative Operatoren auch. Im Falle eines kurz Operand, zuerst die ganzzahlige Aktionen werden ab Abschnitt angewendet 6.3.1.1 Boolesche Werte, Zeichen und ganze Zahlen was sagt:

Wenn ein int alle Werte des ursprünglichen Typs darstellen kann, wird der Wert in einen int konvertiert; andernfalls wird es in ein unsigned int umgewandelt.
Diese werden als Integer-Promotions bezeichnet.⁴⁸⁾ Alle anderen Typen bleiben von den Integer-Promotions unverändert.

Die Diskussion aus Abschnitt 6.3.1.1 des Begründung oder Internationaler Standard – Programmiersprachen – C an ganzzahlige Aktionen ist eigentlich interessanter, ich werde selektiv zitieren, weil es zu lang ist, um es vollständig zu zitieren:

Implementierungen fielen hinein zwei große Lager was charakterisiert werden kann als unsigned Erhaltung und Werterhaltung.

[…]

Die unsigned konservierender Ansatz fordert die Heraufstufung der beiden kleineren unsigned-Typen auf unsigned int. Dies ist eine einfache Regel und ergibt einen Typ, der von der Ausführungsumgebung unabhängig ist.

Die werterhaltender Ansatz Aufrufe zum Heraufstufen dieser Typen zu signed int, wenn dieser Typ alle Werte des ursprünglichen Typs richtig darstellen kann, und andernfalls zum Heraufstufen dieser Typen zu unsigned int. Wenn also die Ausführungsumgebung short als etwas Kleineres als int darstellt, wird unsigned short zu int; andernfalls wird es unsigned int.

Dies kann in einigen Fällen zu ziemlich unerwarteten Ergebnissen führen, da das inkonsistente Verhalten der impliziten Konvertierung zwischen vorzeichenlosen und größeren vorzeichenbehafteten Typen demonstriert, es gibt viele weitere Beispiele dafür. Obwohl dies in den meisten Fällen dazu führt, dass die Vorgänge wie erwartet funktionieren.

Es ist weniger ein Merkmal der Sprache als vielmehr eine Einschränkung der physischen Prozessorarchitekturen, auf denen der Code ausgeführt wird. Die int Typer in C hat normalerweise die Größe Ihres Standard-CPU-Registers. Mehr Silizium nimmt mehr Platz und mehr Leistung ein, sodass in vielen Fällen Arithmetik nur mit den Datentypen „natürlicher Größe“ durchgeführt werden kann. Dies trifft nicht allgemein zu, aber die meisten Architekturen haben immer noch diese Einschränkung. Mit anderen Worten, wenn zwei 8-Bit-Zahlen addiert werden, ist das, was tatsächlich im Prozessor vor sich geht, eine Art 32-Bit-Arithmetik, gefolgt von entweder einer einfachen Bitmaske oder einer anderen geeigneten Typumwandlung.

short und char Typen werden von der Standardart “Speichertypen” betrachtet, dh Teilbereiche, die Sie verwenden können, um etwas Platz zu sparen, die Ihnen jedoch keine Geschwindigkeit verschaffen, da ihre Größe für die CPU “unnatürlich” ist.

Auf bestimmten CPUs ist dies nicht wahr, aber gute Compiler sind schlau genug zu bemerken, dass, wenn Sie zB eine Konstante zu einem unsigned char hinzufügen und das Ergebnis wieder in einem unsigned char speichern, es nicht nötig ist, durch die zu gehen unsigned char -> int Wandlung. Beispielsweise wird mit g++ der Code für die innere Schleife von generiert

void incbuf(unsigned char *buf, int size) {
    for (int i=0; i<size; i++) {
        buf[i] = buf[i] + 1;
    }
}

ist nur

.L3:
    addb    $1, (%rdi,%rax)
    addq    $1, %rax
    cmpl    %eax, %esi
    jg  .L3
.L1:

wo Sie sehen können, dass eine unsignierte Zeichenadditionsanweisung (addb) wird genutzt.

Dasselbe passiert, wenn Sie Ihre Berechnungen zwischen short ints durchführen und das Ergebnis in short ints speichern.

Die verknüpfte Frage scheint es ziemlich gut abzudecken: Die CPU tut es einfach nicht. Eine 32-Bit-CPU hat ihre nativen arithmetischen Operationen für 32-Bit-Register eingerichtet. Der Prozessor arbeitet lieber in seiner bevorzugten Größe, und für Operationen wie diese ist es billig, einen kleinen Wert in ein Register mit nativer Größe zu kopieren. (Bei der x86-Architektur werden die 32-Bit-Register so benannt, als wären sie erweiterte Versionen der 16-Bit-Register (eax zu ax, ebx zu bx, etc); sehen x86-Integer-Anweisungen).

Für einige sehr häufige Operationen, insbesondere Vektor-/Float-Arithmetik, kann es spezielle Anweisungen geben, die mit einem anderen Registertyp oder einer anderen Registergröße arbeiten. Für so etwas wie ein kurzes Auffüllen mit (bis zu) 16 Bits Nullen hat es sehr geringe Leistungskosten und das Hinzufügen spezialisierter Anweisungen ist wahrscheinlich nicht die Zeit oder den Platz auf dem Würfel wert (wenn Sie wirklich wissen wollen, warum; ich bin Ich bin mir nicht sicher, ob sie tatsächlich Platz einnehmen würden, aber es wird viel komplexer).