Warum hatte C vor C99 keinen booleschen Datentyp?

Ich weiß, Sie können einfach #define einige Ganzzahlen, aber warum hatte C vor C99 keinen dedizierten booleschen Datentyp?

Es ist ein so häufiges Vorkommen in der Programmierung und Logik, dass ich das Fehlen eines expliziten Typs und einer expliziten Notation nicht verstehe.

Wenn Sie ein wenig Zeit in der Bibliothek verbringen, müssen Sie nicht spekulieren. Hier sind einige Aussagen entnommen Dennis Ritchies Artikel über die Evolution von C. Der Kontext ist, dass Dennis auf Ken Thompsons Sprache B aufbaut, die auf dem sehr winzigen PDP-7, einer wortadressierten Maschine, implementiert wurde. Aufgrund des wachsenden Interesses bekam die Gruppe einen der allerersten PDP-11. Dennis schreibt,

Das Aufkommen des PDP-11 deckte mehrere Unzulänglichkeiten des semantischen Modells von B auf. Erstens waren seine Zeichenbehandlungsmechanismen, die mit wenigen Änderungen von BCPL geerbt wurden, ungeschickt: Die Verwendung von Bibliotheksprozeduren, um gepackte Zeichenfolgen in einzelne Zellen zu verteilen und dann neu zu packen, oder um auf einzelne Zeichen zuzugreifen und sie zu ersetzen, fing an, sich umständlich, sogar albern, anzufühlen byteorientierte Maschine.

Das B- und BCPL-Modell implizierte einen Overhead beim Umgang mit Zeigern: Die Sprachregeln erzwangen durch die Definition eines Zeigers als Index in einem Array von Wörtern die Darstellung von Zeigern als Wortindizes. Jede Zeigerreferenz erzeugte eine Laufzeitskalenumwandlung von dem Zeiger zu der von der Hardware erwarteten Byteadresse.

Aus all diesen Gründen schien ein Typisierungsschema notwendig zu sein, um mit der Zeichen- und Byte-Adressierung fertig zu werden und um sich auf die kommende Gleitkomma-Hardware vorzubereiten. Vor allem andere Themen Typsicherheit und Schnittstellenprüfung schienen damals nicht so wichtig zu sein, wie sie später wurden.

(Hervorhebung von mir.)

Der Aufsatz beschreibt dann Dennis’ Bemühungen, eine neue Zeigersemantik zu erfinden, Arrays zum Laufen zu bringen und sich mit diesem Neumodischen abzufinden struct Idee. Begriffe zur Typsicherheit und zur Unterscheidung von Booleschen Werten von ganzen Zahlen schienen erst viel später wichtig zu sein 🙂

C ist eigentlich kaum mehr als eine Assemblersprache auf höherer Ebene. Ja, es hat Kontrollstrukturen und so weiter und es hat sogar Typen, die Assembler sicherlich nicht braucht.

Aber die Sprache wurde vor Jahrzehnten entworfen. Und da jedes boolesche Ergebnis auf einzelne Bits im Statuswort des Prozessors herunterfällt, reichte es offensichtlich aus, nur einen ganzzahligen Datentyp dafür zu verwenden. Und es hat den Compiler wahrscheinlich etwas weniger komplex gemacht, da Sie einige Typprüfungen weglassen können (in späteren Sprachen Kontrollstrukturen brauchen ein boolescher Wert, in C brauchen sie nur einen ganzzahligen Wert von entweder 0 oder etwas anderem).

Eine CPU hat keinen “booleschen Typ”, sie arbeitet nur mit Bytes und Vielfachen davon, daher machte ein boolescher Typ zu diesem Zeitpunkt keinen Sinn, da er keinen Vorteil brachte (warum einen Typ verwenden, wenn Sie nur “ist 0” überprüfen können). oder “ist nicht null”)

Es war üblich (und ist es in einigen Fällen immer noch), Null als falsch und alle Nicht-Null-Werte als wahr zu behandeln. Das hat Vorteile für die Kurzschrift: zum Beispiel statt while (remaining != 0) kannst du einfach verwenden while (remaining).

Einige Sprachen sind auf das wahre Sein -1 standardisiert. Der Grund dafür ist, dass in der Zweierkomplementnotation (die die meisten Computer verwenden, um negative Zahlen darzustellen) das bitweise Nicht von 0 -1 ist (in 8-Bit-Binär , 11111111 ist dezimal -1).

Im Laufe der Zeit wurde klar, dass die Verwendung einer vom Compiler definierten Konstante eine Menge potenzieller Verwirrung verhindern würde. Es ist schon eine Weile her, seit ich C++ gemacht habe, aber ich bin mir ziemlich sicher, dass jeder Wert ungleich Null immer noch “true” auswerten wird.

Ich vermute, es wurde als ausreichend angesehen, einen ganzzahligen Typ zu haben, wobei 0 falsch und alles, was nicht 0 ist, wahr ist.

Dem alten C “fehlte” nicht wirklich ein boolescher Typ – es war nur so, dass alle ganzzahligen Typen auch als geeignet angesehen wurden, um doppelte Aufgaben auszuführen und boolesche Werte zu speichern. Dafür sehe ich zwei Hauptgründe:

• Prozessoren mit Bitadressierung waren überhaupt nicht üblich (und sind es immer noch nicht), sodass der Compiler nicht wirklich in der Lage wäre, einen “echten booleschen” Typ zu verwenden, um Platz zu sparen – der boolesche Wert wäre immer noch mindestens so groß wie a char sowieso (wenn Sie gehofft haben, effizient darauf zugreifen zu können).

• Typen schmaler als int werden erweitert int in Ausdrücken sowieso – also würden die booleschen Operatoren immer noch funktionieren int Operanden.

.. es sieht also so aus, als gäbe es keinen überzeugenden Fall, dass ein dedizierter boolescher Typ tatsächlich praktische Vorteile bringen würde.

Denken Sie daran, dass die C-Sprache eine Reihe von Operatoren hat, die boolesche Ergebnisse erzeugen (entweder als 0 oder 1 definiert) – !, &&, ||, !=, ==, <, <=, > und >= – es ist also nur ein dedizierter boolescher Typ, der nicht vorhanden ist.

Der Typ, den Sie zum Speichern eines booleschen Werts verwenden, verkörpert (normalerweise) einen Kompromiss zwischen Raum und Zeit. Normalerweise erhalten Sie die schnellsten Ergebnisse (zumindest für eine einzelne Operation), indem Sie ein int (normalerweise vier Bytes) verwenden. Wenn Sie andererseits sehr viele verwenden, kann es viel sinnvoller sein, ein Byte zu verwenden oder sie sogar so zu packen, dass jeder Wert, den Sie speichern, nur ein einziges Bit verwendet – aber wenn/falls Sie das tun, das Lesen oder Schreiben eines einzelnen Bits wird wesentlich teurer (und erfordert zusätzlichen Code).

Da es keine Antwort gab, die wirklich „richtig“ war, überließen sie die Entscheidung dem Benutzer, basierend auf den Anforderungen des Programms, das er schrieb.

Die eigentliche Frage ist also, warum in C99 ein boolescher Typ hinzugefügt wurde. Meine Vermutung ist, dass ein paar Faktoren eine Rolle spielen. Erstens erkannten sie, dass Lesbarkeit und Benutzerfreundlichkeit für den Programmierer heute normalerweise wichtiger sind, als die absolut bestmögliche Leistung zu erbringen. Zweitens führen Compiler jetzt viel mehr globale Analysen durch, sodass es zumindest möglich ist, jemanden zu erraten könnte Schreiben Sie einen Compiler, der versucht, eine Darstellung auszuwählen, die für ein bestimmtes Programm am besten geeignet ist (obwohl ich keinen kenne, der das wirklich tut).