Welche Plattformen haben etwas anderes als 8-Bit-Zeichen?

136

Hin und wieder weist jemand auf SO darauf hin, dass char(auch bekannt als "Byte") nicht unbedingt 8 Bits sind .

Es scheint, dass 8-Bit charfast universell ist. Ich hätte gedacht, dass es für Mainstream-Plattformen notwendig ist, ein 8-Bit charzu haben, um seine Lebensfähigkeit auf dem Markt sicherzustellen.

Welche Plattformen verwenden jetzt und in der Vergangenheit eine char, die nicht 8 Bit beträgt, und warum sollten sie sich von den "normalen" 8 Bit unterscheiden?

Welche Überlegungen sollten beim Schreiben von Code und beim Nachdenken über plattformübergreifende Unterstützung (z. B. für allgemein verwendete Bibliotheken) Plattformen mit Nicht-8-Bit-Funktionen berücksichtigt werden char?

In der Vergangenheit bin ich auf einige DSPs von Analog Devices gestoßen, für die char16 Bit verfügbar sind. DSPs sind wohl eine Art Nischenarchitektur. (Andererseits übertraf der handcodierte Assembler zu dieser Zeit leicht die Möglichkeiten der verfügbaren C-Compiler, sodass ich auf dieser Plattform nicht wirklich viel Erfahrung mit C gesammelt habe.)

Craig McQueen
quelle
9
Die CDC Cyber-Serie hatte eine 6/12-Bit-Codierung. Die beliebtesten Zeichen waren 6 Bit. Die restlichen Zeichen verwendeten 12 Bit.
Thomas Matthews
2
Der PDP-11 hat es festgenagelt. Die Vorstellung, dass ein Zeichen in einem Zeichen codiert werden kann, ist ernsthaft überholt.
Hans Passant
7
"Der PDP-11 hat es geschafft" - Sie meinen, weil C zuerst für den PDP-11 mit 8-Bit-Bytes implementiert wurde? Als nächstes wurde C für Honeywell-Maschinen mit 9-Bit-Bytes implementiert. Siehe K & R Version 1. Außerdem wurde die Frage nach char (dh Byte) und nicht nach Zeichen gestellt (ein oder mehrere Bytes, die etwas codieren, nach dem nicht gefragt wurde).
Windows-Programmierer
6
DEC-10 und DEC-20 hatten 36-Bit-Wörter. Fünf 7-Bit-ASCII-Zeichen pro Wort waren weit verbreitet. Es wurden auch sechs 6-Bit-Zeichen verwendet.
David R Tribble
3
@CraigMcQueen: Wenn ich mich richtig erinnere, können Sie mit CodeVision für Atmel-Mikrocontroller die Größe von char
vsz

Antworten:

80

charist auch 16 Bit auf den Texas Instruments C54x DSPs, die zum Beispiel in OMAP2 aufgetaucht sind. Es gibt andere DSPs mit 16 und 32 Bit char. Ich glaube, ich habe sogar von einem 24-Bit-DSP gehört, aber ich kann mich nicht erinnern, was, also habe ich es mir vielleicht vorgestellt.

Eine weitere Überlegung ist, dass POSIX Mandate CHAR_BIT == 8. Wenn Sie also POSIX verwenden, können Sie davon ausgehen. Wenn jemand später Ihren Code auf eine nahezu Implementierung von POSIX portieren muss, hat dies zufällig die von Ihnen verwendeten Funktionen, aber eine andere Größe char, das ist sein Pech.

Im Allgemeinen denke ich jedoch, dass es fast immer einfacher ist, das Problem zu umgehen, als darüber nachzudenken. Geben Sie einfach ein CHAR_BIT. Wenn Sie einen genauen 8-Bit-Typ wünschen, verwenden Sie int8_t. Ihr Code kann bei Implementierungen, die keine bereitstellen, geräuschvoll kompiliert werden, anstatt stillschweigend eine Größe zu verwenden, die Sie nicht erwartet haben. Zumindest würde ich es behaupten, wenn ich auf einen Fall stoßen würde, in dem ich einen guten Grund hatte, ihn anzunehmen.

Steve Jessop
quelle
2
TI C62xx- und C64xx-DSPs verfügen ebenfalls über 16-Bit-Zeichen. (uint8_t ist auf dieser Plattform nicht definiert.)
myron-semack
7
Viele DSPs für die Audioverarbeitung sind 24-Bit-Maschinen. die BelaSigna DSPs von On Semi (nachdem sie AMI Semi gekauft haben); die DSP56K / Symphony Audio DSPs von Freescale (nachdem sie von Motorola ausgegliedert wurden).
David Cary
2
@msemack C64xx hat Hardware für 16.08.32/40 und 8-Bit-
Zeichen
4
Anstatt assert()(wenn Sie das gemeint haben) würde ich #if CHAR_BIT != 8... #error "I require CHAR_BIT == 8"...#endif
Keith Thompson
1
@KeithThompson Gibt es einen Grund, nicht zu verwenden static_assert()?
Qix - MONICA wurde
37

Welche Überlegungen sollten beim Schreiben von Code und beim Nachdenken über plattformübergreifende Unterstützung (z. B. für Bibliotheken mit allgemeiner Verwendung) Plattformen mit Nicht-8-Bit-Zeichen berücksichtigt werden?

Es ist nicht so sehr, dass es sich lohnt, über etwas nachzudenken, sondern dass es sich an die Regeln hält. In C ++ sagt der Standard beispielsweise, dass alle Bytes "mindestens" 8 Bits haben. Wenn Ihr Code davon ausgeht, dass Bytes genau 8 Bit haben, verstoßen Sie gegen den Standard.

Das mag jetzt albern erscheinen - " Natürlich haben alle Bytes 8 Bits!", Höre ich Sie sagen. Aber viele sehr kluge Leute haben sich auf Annahmen verlassen, die keine Garantien waren, und dann ist alles kaputt gegangen. Die Geschichte ist voll von solchen Beispielen.

Zum Beispiel gingen die meisten Entwickler Anfang der 90er Jahre davon aus, dass eine bestimmte No-Op-CPU-Zeitverzögerung, die eine feste Anzahl von Zyklen benötigt, eine feste Taktzeit in Anspruch nehmen würde, da die meisten Consumer-CPUs in etwa gleich leistungsfähig waren. Leider wurden Computer sehr schnell schneller. Dies führte zur Entstehung von Boxen mit "Turbo" -Tasten - deren Zweck ironischerweise darin bestand, den Computer zu verlangsamen, damit Spiele mit der Zeitverzögerungstechnik mit einer angemessenen Geschwindigkeit gespielt werden konnten.


Ein Kommentator fragte, wo im Standard steht, dass char mindestens 8 Bits haben muss. Es ist in Abschnitt 5.2.4.2.1 . Dieser Abschnitt definiert CHAR_BITdie Anzahl der Bits in der kleinsten adressierbaren Entität und hat einen Standardwert von 8. Außerdem heißt es:

Ihre implementierungsdefinierten Werte müssen gleich oder größer (absoluter Wert) sein als die angegebenen Werte mit demselben Vorzeichen.

Daher ist jede Zahl gleich 8 oder höher für die Substitution durch eine Implementierung in geeignet CHAR_BIT.

John Feminella
quelle
6
Ich habe seit mindestens 20 Jahren keinen Turbo-Knopf mehr gesehen. Glaubst du wirklich, dass die Frage von Bedeutung ist?
Mark Ransom
29
@ Mark Ransom: Das ist der springende Punkt. Entwickler verlassen sich oft auf Annahmen, die im Moment wahr zu sein scheinen, aber viel wackeliger sind, als sie zunächst erscheinen. (Ich kann nicht zählen, wie oft ich diesen Fehler gemacht habe!) Die Turbo-Taste sollte eine schmerzhafte Erinnerung sein, keine unnötigen Annahmen zu treffen und sicherlich keine Annahmen zu treffen, die nicht durch einen Sprachstandard garantiert werden, als ob sie es wären unveränderliche Tatsachen.
John Feminella
1
Könnten Sie darauf hinweisen, in C ++ Standard zu platzieren, der besagt, dass das Tschüss mindestens 8 Bit hat? Es ist eine verbreitete Überzeugung, aber ich persönlich habe es nicht im Standard gefunden. Das einzige, was ich in Standard gefunden habe, ist, welche Zeichen durch charmehr als 64 von ihnen darstellbar sein müssen, aber weniger als 128, also würden 7 Bits ausreichen.
Adam Badura
6
Abschnitt 18.2.2 ruft den C-Standard dafür auf. Im C-Standard ist es Abschnitt 7.10 und dann Abschnitt 5.4.2.4.1. Seite 22 im C-Standard.
Windows-Programmierer
2
Andere Antworten und Kommentare erwähnen also Maschinen mit 5-Bit-, 6-Bit- und 7-Bit-Bytes. Bedeutet das, dass Sie auf diesem Computer kein C-Programm ausführen können, das dem Standard entspricht?
Jerry Jeremiah
34

Maschinen mit 36-Bit-Architekturen haben 9-Bit-Bytes. Laut Wikipedia gehören zu Maschinen mit 36-Bit-Architekturen :

  • Digital Equipment Corporation PDP-6/10
  • IBM 701/704/709/7090/7094
  • UNIVAC 1103 / 1103A / 1105/1100/2200,
R Samuel Klatchko
quelle
7
Auch Honeywell-Maschinen, wie vielleicht die zweite Maschine, auf der C implementiert wurde. Siehe K & R Version 1.
Windows-Programmierer
5
Eigentlich hatte die Dez-10 auch 6-Bit - Zeichen - Sie 6 davon in ein 36-Bit - Wort (ex-Dec-10 Programmierer sprechen) packen könnten
2
Der DEC-20 verwendete fünf 7-Bit-ASCII-Zeichen pro 36-Bit-Wort auf dem TOPS-20 O / S.
David R Tribble
3
Dieser Witz wurde tatsächlich implementiert, um Unicode auf dieser Architektur zu unterstützen.
Joshua
9
Ich stelle mir vor, dass der Grund, warum Oktal jemals tatsächlich verwendet wurde, darin bestand, dass 3 Oktalstellen ein 9-Bit-Byte genau darstellen, so wie wir es heute normalerweise hexadezimal verwenden, weil zwei Hexadezimalstellen ein 8-Bit-Byte genau darstellen.
Bames53
18

Einige davon sind mir bekannt:

  • DEC PDP-10: variabel, aber meistens 7-Bit-Zeichen, gepackt mit 5 pro 36-Bit-Wort oder 9-Bit-Zeichen, 4 pro Wort
  • Steuerdaten-Mainframes (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 usw.) 6-Bit-Zeichen, 10 pro 60-Bit-Wort.
  • Unisys-Mainframes: 9 Bit / Byte
  • Windows CE: unterstützt den Typ "char" einfach überhaupt nicht - erfordert stattdessen 16-Bit-wchar_t
Jerry Sarg
quelle
2
@ephemient: Ich bin mir ziemlich sicher, dass es mindestens einen (vorstandardisierten) C-Compiler für PDP-10 / DecSystem 10 / DecSystem 20 gab. Ich wäre jedoch sehr überrascht über einen C-Compiler für die CDC-Mainframes (das waren sie) wird hauptsächlich für numerische Arbeiten verwendet, daher war der Fortran-Compiler dort die große Sache. Ich bin mir ziemlich sicher, dass die anderen C-Compiler haben.
Jerry Coffin
3
Hat der Windows CE-Compiler den charTyp wirklich überhaupt nicht unterstützt ? Ich weiß, dass die Systembibliotheken nur die Wide-Char-Versionen von Funktionen unterstützen, die Zeichenfolgen enthalten, und dass zumindest einige Versionen von WinCE die ANSI-Zeichenfolgenfunktionen wie strlen entfernt haben, um zu verhindern, dass Sie Zeichenfolgen verarbeiten. Aber hatte es wirklich überhaupt keinen Char-Typ? Was war sizeof(TCHAR)? Welchen Typ hat Malloc zurückgegeben? Wie wurde der Java- byteTyp implementiert?
Steve Jessop
10
Windows CE unterstützt char, ein Byte. Siehe Craig McQueens Kommentar zu Richard Penningtons Antwort. Bytes werden in Windows CE genauso benötigt wie überall sonst, egal welche Größe sie überall haben.
Windows-Programmierer
2
Es gibt (waren?) Mindestens zwei Implementierungen von C für den PDP-10: KCC und einen Port von gcc ( pdp10.nocrew.org/gcc ).
AProgrammer
3
Der C-Standard würde weder 7-Bit-Zeichen zulassen, die 5 pro 36-Bit-Wort gepackt sind (wie Sie für den PDP-10 erwähnt haben), noch 6-Bit-Zeichen zulassen, wie Sie für die Control Data-Mainframes erwähnt haben. Siehe parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
Ken Bloom
15

Es gibt keinen vollständig portablen Code. :-)

Ja, es kann verschiedene Byte- / Zeichengrößen geben. Ja, es gibt möglicherweise C / C ++ - Implementierungen für Plattformen mit sehr ungewöhnlichen Werten von CHAR_BITund UCHAR_MAX. Ja, manchmal ist es möglich, Code zu schreiben, der nicht von der Zeichengröße abhängt.

Fast jeder echte Code ist jedoch nicht eigenständig. Beispielsweise schreiben Sie möglicherweise einen Code, der Binärnachrichten an das Netzwerk sendet (Protokoll ist nicht wichtig). Sie können Strukturen definieren, die erforderliche Felder enthalten. Dann müssen Sie es serialisieren. Nur das binäre Kopieren einer Struktur in einen Ausgabepuffer ist nicht portierbar: Im Allgemeinen kennen Sie weder die Bytereihenfolge für die Plattform noch die Ausrichtung der Strukturelemente, sodass die Struktur nur die Daten enthält, aber nicht beschreibt, wie die Daten serialisiert werden sollen .

OK. Sie können Transformationen der Bytereihenfolge durchführen und die Strukturelemente (z. B. uint32_toder ähnliches) mithilfe memcpyin den Puffer verschieben. Warum memcpy? Weil es viele Plattformen gibt, auf denen es nicht möglich ist, 32-Bit (16-Bit, 64-Bit - kein Unterschied) zu schreiben, wenn die Zieladresse nicht richtig ausgerichtet ist.

Sie haben also bereits viel getan, um Portabilität zu erreichen.

Und jetzt die letzte Frage. Wir haben einen Puffer. Die Daten davon werden an das TCP / IP-Netzwerk gesendet. Ein solches Netzwerk nimmt 8-Bit-Bytes an. Die Frage ist: Von welchem ​​Typ sollte der Puffer sein? Wenn Ihre Zeichen 9-Bit sind? Wenn sie 16-Bit sind? 24? Vielleicht entspricht jedes Zeichen einem 8-Bit-Byte, das an das Netzwerk gesendet wird, und es werden nur 8 Bit verwendet? Oder sind mehrere Netzwerkbytes in 24/16/9-Bit-Zeichen gepackt? Das ist eine Frage, und es ist kaum zu glauben, dass es eine einzige Antwort gibt, die in alle Fälle passt. Viele Dinge hängen von der Socket-Implementierung für die Zielplattform ab.

Also, wovon ich spreche. Normalerweise kann Code bis zu einem gewissen Grad relativ leicht portierbar gemacht werden . Dies ist sehr wichtig, wenn Sie den Code auf verschiedenen Plattformen verwenden möchten. Die Verbesserung der Portabilität über diese Maßnahme hinaus erfordert jedoch viel Aufwand und ist häufig wenig sinnvoll , da der tatsächliche Code fast immer von anderem Code abhängt (Socket-Implementierung im obigen Beispiel). Ich bin sicher, dass für etwa 90% des Codes die Fähigkeit, auf Plattformen mit anderen Bytes als 8-Bit zu arbeiten, fast nutzlos ist, da eine Umgebung verwendet wird, die an 8-Bit gebunden ist. Überprüfen Sie einfach die Bytegröße und führen Sie die Bestätigung der Kompilierungszeit durch. Für eine höchst ungewöhnliche Plattform müssen Sie mit ziemlicher Sicherheit viel umschreiben.

Aber wenn Ihr Code sehr "eigenständig" ist - warum nicht? Sie können es so schreiben, dass unterschiedliche Bytegrößen möglich sind.

Ellioh
quelle
4
Wenn ein Oktett pro unsigned charWert gespeichert wird, sollten keine Portabilitätsprobleme auftreten, es sei denn, der Code verwendet Aliasing-Tricks anstelle von Verschiebungen, um Oktettsequenzen in / von größeren Ganzzahltypen zu konvertieren. Persönlich denke ich, dass der C-Standard Eigenheiten definieren sollte, um Ganzzahlen aus Sequenzen kürzerer Typen (am typischsten char) zu packen / zu entpacken, wobei eine feste garantierte verfügbare Anzahl von Bits pro Element (8 pro unsigned char, 16 pro unsigned shortoder 32 pro unsigned long) gespeichert wird .
Supercat
9

Es scheint, dass Sie immer noch einen IM6100 (dh einen PDP-8 auf einem Chip) aus einem Lager kaufen können . Das ist eine 12-Bit-Architektur.

dmckee --- Ex-Moderator Kätzchen
quelle
9

Viele DSP-Chips haben 16- oder 32-Bit char. TI stellt solche Chips beispielsweise routinemäßig her .

Alok Singhal
quelle
5

Die Programmiersprachen C und C ++ definieren beispielsweise Byte als "adressierbare Dateneinheit, die groß genug ist, um ein Mitglied des Grundzeichensatzes der Ausführungsumgebung aufzunehmen" (Abschnitt 3.6 des C-Standards). Da der Datentyp C char Integral mindestens 8 Bits enthalten muss (Abschnitt 5.2.4.2.1), kann ein Byte in C mindestens 256 verschiedene Werte enthalten. Verschiedene Implementierungen von C und C ++ definieren ein Byte als 8, 9, 16, 32 oder 36 Bit

Zitiert aus http://en.wikipedia.org/wiki/Byte#History

Ich bin mir jedoch nicht sicher über andere Sprachen.

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

Definiert ein Byte auf diesem Computer mit variabler Länge

Petantik
quelle
1
"Bei anderen Sprachen nicht sicher" - Historisch gesehen erlaubten die meisten Sprachen der Architektur der Maschine, ihre eigene Bytegröße zu definieren. Historisch gesehen auch C, bis der Standard eine Untergrenze von 8 festlegte.
Windows-Programmierer
4

Die DEC PDP-8-Familie hatte ein 12-Bit-Wort, obwohl Sie normalerweise 8-Bit-ASCII für die Ausgabe verwendeten (meistens auf einem Teletyp). Es gab jedoch auch einen 6-BIT-Zeichencode, mit dem Sie 2 Zeichen in einem einzelnen 12-Bit-Wort codieren konnten.

PrgTrdr
quelle
3

Zum einen sind Unicode-Zeichen länger als 8 Bit. Wie bereits erwähnt, definiert die C-Spezifikation Datentypen anhand ihrer Mindestgröße. Verwenden Sie sizeofund die Werte in, limits.hwenn Sie Ihre Datentypen abfragen und genau herausfinden möchten, welche Größe sie für Ihre Konfiguration und Architektur haben.

Aus diesem Grund versuche ich, mich an Datentypen zu halten, beispielsweise uint16_twenn ich einen Datentyp mit einer bestimmten Bitlänge benötige.

Edit: Sorry, ich habe deine Frage zunächst falsch verstanden.

Die C-Spezifikation besagt, dass ein charObjekt "groß genug ist, um ein Mitglied des Ausführungszeichensatzes zu speichern". limits.hlistet eine minimale Größe von 8 Bit auf, aber die Definition lässt die maximale Größe eines charoffen.

Somit ist das a charmindestens so lang wie das größte Zeichen aus dem Ausführungssatz Ihrer Architektur (normalerweise auf die nächste 8-Bit-Grenze aufgerundet). Wenn Ihre Architektur längere Opcodes enthält, ist Ihre charGröße möglicherweise länger.

In der Vergangenheit war der Opcode der x86-Plattform ein Byte lang, also charzunächst ein 8-Bit-Wert. Aktuelle x86-Plattformen unterstützen Opcodes, die länger als ein Byte sind, aber die charLänge beträgt 8 Bit, da Programmierer (und die großen Mengen des vorhandenen x86-Codes) darauf konditioniert sind.

Nutzen Sie die in definierten Typen, wenn Sie über die Unterstützung mehrerer Plattformen nachdenken stdint.h. Wenn Sie (zum Beispiel) ein uint16_t verwenden, dann können Sie sicher sein , dass dieser Wert ist ein unsigned 16-Bit - Wert aus welcher Architektur, ob die 16-Bit - Wert entspricht einen char, short, int, oder etwas anderes. Die meiste harte Arbeit wurde bereits von den Leuten geleistet, die Ihre Compiler- / Standardbibliotheken geschrieben haben.

Wenn Sie die genaue Größe von a kennen müssen, charweil Sie eine Hardwaremanipulation auf niedriger Ebene durchführen, die dies erfordert, verwende ich normalerweise einen Datentyp, der groß genug ist, um a charauf allen unterstützten Plattformen zu speichern (normalerweise sind 16 Bit ausreichend) und auszuführen der Wert durch eine convert_to_machine_charRoutine, wenn ich die genaue Maschinendarstellung brauche. Auf diese Weise ist der plattformspezifische Code auf die Schnittstellenfunktion beschränkt und meistens kann ich einen normalen Code verwenden uint16_t.

bta
quelle
2
Bei der Frage wurde nicht nach Zeichen gefragt (ob Unicode oder nicht). Es wurde nach char gefragt, was ein Byte ist.
Windows-Programmierer
1
Außerdem hat der Ausführungszeichensatz nichts mit Opcodes zu tun. Es ist der Zeichensatz, der bei der Ausführung verwendet wird. Denken Sie an Cross-Compiler.
Ninjalj
"Historisch gesehen war der Opcode der x86-Plattform ein Byte lang": wie süß. Historisch gesehen wurde C auf einem PDP-11 (1972) entwickelt, lange bevor x86 erfunden wurde (1978).
Martin Bonner unterstützt Monica
3

Welche Überlegung lohnt sich für Plattformen mit Nicht-8-Bit-Zeichen?

magische Zahlen treten zB beim Verschieben auf;

Die meisten davon können ganz einfach mit CHAR_BIT und z. B. UCHAR_MAX anstelle von 8 und 255 (oder ähnlichem) behandelt werden.

hoffentlich definiert deine Implementierung diese :)

das sind die "gemeinsamen" Probleme .....

Ein weiteres indirektes Problem ist, dass Sie Folgendes haben:

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

Dies kann "nur" (im besten Fall) 24 Bit auf einer Plattform dauern, aber zB 72 Bit an anderer Stelle .....

Wenn jeder Uchar "Bit-Flags" enthielt und jeder Uchar nur 2 "signifikante" Bits oder Flags hatte, die Sie gerade verwendeten, und Sie sie aus "Klarheit" nur in 3 Uchars organisiert haben, ist dies möglicherweise relativ "verschwenderischer", z eine Plattform mit 24-Bit-Uchars .....

Nichts, was Bitfelder nicht lösen können, aber sie müssen auf andere Dinge achten ...

In diesem Fall kann nur eine einzige Aufzählung eine Möglichkeit sein, die "kleinste" Ganzzahl zu erhalten, die Sie tatsächlich benötigen.

vielleicht kein wirkliches Beispiel, aber solche Sachen "haben" mich beim Portieren / Spielen mit Code "gebissen" .....

Nur die Tatsache, dass, wenn ein Uchar dreimal so groß ist wie "normalerweise" erwartet, 100 solcher Strukturen auf einigen Plattformen viel Speicher verschwenden könnten ... wo "normalerweise" keine große Sache ist ... .

Daher können die Dinge immer noch "kaputt" sein oder in diesem Fall "sehr schnell viel Speicher verschwenden", da angenommen wird, dass ein Ukar auf einer Plattform im Verhältnis zum verfügbaren RAM "nicht sehr verschwenderisch" ist als auf einer anderen Plattform ... ..

Das Problem könnte z. B. auch für Ints oder andere Typen auftreten, z. B. wenn Sie eine Struktur haben, die 15 Bit benötigt, also stecken Sie sie in ein Int, aber auf einer anderen Plattform ist ein Int 48 Bit oder was auch immer .... .

"normal" könnten Sie es in 2 Uchars aufteilen, aber zB mit einem 24-Bit-Uchar würden Sie nur einen brauchen .....

Eine Aufzählung könnte also eine bessere "generische" Lösung sein ...

hängt davon ab, wie Sie auf diese Bits zugreifen :)

Es kann also zu "Designfehlern" kommen, die ihren Kopf aufrichten ... selbst wenn der Code ungeachtet der Größe eines Ukar oder Uint immer noch einwandfrei funktioniert / läuft ...

Es gibt solche Dinge, auf die Sie achten müssen, obwohl Ihr Code keine "magischen Zahlen" enthält ...

hoffe das macht Sinn :)

dd ee
quelle
1
...Was? Warum ist es Ihrer Meinung enumnach wahrscheinlich kleiner als bei anderen einheimischen Typen? Ist Ihnen bewusst, dass standardmäßig derselbe Speicher verwendet wird wie int? "Sie haben eine Struktur, die 15 Bit benötigt, also stecken Sie sie in ein Int, aber auf einer anderen Plattform ist ein Int 48 Bit oder was auch immer ....." - also #include <cstdint>machen Sie es zu einer int16_tfür die beste Chance, die Bitverwendung zu minimieren . Ich bin mir wirklich nicht sicher, was Sie unter all diesen Ellipsen gesagt haben.
underscore_d
1

Ints waren früher 16 Bit (pdp11 usw.). Es war schwierig, auf 32-Bit-Architekturen umzusteigen. Die Leute werden besser: Kaum jemand geht davon aus, dass ein Zeiger mehr passt (stimmt das nicht?). Oder Datei-Offsets oder Zeitstempel oder ...

8-Bit-Zeichen sind bereits ein Anachronismus. Wir benötigen bereits 32 Bit, um alle Zeichensätze der Welt aufzunehmen.

Richard Pennington
quelle
2
Wahr. Der Name charist jetzt in Unicode-Tagen etwas kurios. Ich kümmere mich mehr um 8-Bit-Einheiten (Oktette) beim Umgang mit Binärdaten, z. B. Dateispeicherung, Netzwerkkommunikation. uint8_tist nützlicher.
Craig McQueen
3
Unicode benötigte eigentlich nie volle 32 Bit. Sie waren ursprünglich für 31 geplant (siehe die ursprüngliche UTF-8-Arbeit), aber jetzt sind sie mit nur 21 Bit zufrieden . Sie erkannten wahrscheinlich, dass sie das Buch nicht mehr drucken könnten, wenn sie tatsächlich alle 31 Bits benötigen würden: P
me22
2
@ me22, Unicode ursprünglich für 16 Bit geplant. "Unicode-Zeichen sind unabhängig von der Sprache konsistent 16 Bit breit ..." Unicode 1.0.0. unicode.org/versions/Unicode1.0.0/ch01.pdf .
Shannon Severance
1
ISO 10646 war ursprünglich 31 Bit und Unicode wurde mit ISO 10646 zusammengeführt, so dass es schlampig sein kann zu sagen, dass Unicode 31 Bit war, aber es ist nicht wirklich falsch. Beachten Sie, dass sie nicht mehr die vollständigen Codetabellen drucken.
Prosfilaes