Als ich heute alten Code durchlas, bemerkte ich die folgende assert -Zeile:
Der Zweck besteht darin, zu bestätigen, dass Ich habe mich gefragt, ob dies immer das tut, was ich beabsichtigt habe, da der Ausführungszeichensatz implementationsdefiniert ist. Der C ++ - Standard in Abschnitt 2.3, Zeichensätze, erwähnt: Der grundlegende Ausführungszeichensatz und der grundlegende Ausführungsbreitenzeichensatz müssen jeweils alle Elemente des grundlegenden Quellzeichensatzes sowie Steuerzeichen enthalten, die für die Warnung, Backspace stehen und Wagenrücklauf sowie ein Nullzeichen ( Null breites Zeichen ), dessen Darstellung alle Null-Bits enthält. Für jeden grundlegenden Ausführungszeichensatz dürfen die Werte der Elemente nicht negativ und voneinander verschieden sein. Sowohl in der Quell- als auch in der Ausführungsbasiszeichensätze muss der Wert jedes Zeichens nach 0 in der obigen Liste von Dezimalziffern eins größer als der Wert der vorhergehenden sein. Der Ausführungszeichensatz und der Ausführungsbreitenzeichensatz sind implementierungsdefinierte Obermengen des grundlegenden Ausführungszeichensatzes bzw. des grundlegenden Ausführungsbreitenzeichensatzes. Die Werte der Mitglieder der Ausführungszeichensätze und der Gruppen zusätzlicher Mitglieder sind länderspezifisch. Ich interpretiere das so, dass Ist das eine korrekte Aussage? Wenn ich nichts über den C ++ - Compiler weiß (also die Implementierungsdetails nicht kenne), muss ich hexChar eine hexadezimale Ziffer ist ([0-9A-Fa-f]). Dies geschieht durch eine ASCII-ähnliche Anordnung von char -Objekten, die 'A' , 'B' , ..., 'F' und 'a' , 'b' , ..., 'f' .
('0' <= hexChar && hexChar <= '9') in Ordnung ist, weil '0' , '1' , ..., '9' Ziffern sind und jeder einen Wert eins größer als der vorherige hat. Die Reihenfolge der anderen grundlegenden Quellzeichen in Bezug aufeinander ist jedoch noch implementationsdefiniert. assert wie folgt neu schreiben?
Die erste Zeile, Vergleich mit den Werten von '0' und '9' ist 100% portabel. Die C-Sprache garantiert, dass sie sich bei allen Implementierungen identisch verhält.
Die zweite und die dritte Zeile sind im Prinzip implementierungsdefiniert, aber es gab und wird nie eine Implementierung sein, bei der sich ihr Verhalten unterscheidet. Die einzige nicht-ISO646-kompatible Zeichencodierung, die je mit der Sprache C verwendet wurde (und der einzige Grund, warum C nicht-ISO646-kompatible Codierungen zulässt) ist EBCDIC, die die Buchstaben 'A' bis 'F' genau dort platziert, wo sie sollten fallen als hexadezimale Werte (im Allgemeinen sind die Buchstaben in EBCDIC nicht zusammenhängend, aber AF sind eine zusammenhängende Gruppe).
Abgesehen davon, dass Sie keine älteren Mainframes unterstützen müssen, gibt es keinen Wert bei der Verarbeitung der grundlegenden Zeichencodierung "portabel" in C. char hat 8 Bits, die Werte 0-127 sind ASCII und die Werte 128-255 sind Teil einer locale- oder datenspezifischen Multibyte-Zeichencodierung, von der wir immer wieder annehmen können, dass sie immer UTF-8 ist.
Zu Ihrer ersten Frage: ja.
Zu Ihrer zweiten Frage: vielleicht, aber wahrscheinlich sollten Sie in Betracht ziehen, die C-Bibliothek isxdigit function oder eine C ++ - Gebietsschema-Variante davon zu verwenden.
Technisch gesehen ist es völlig legal, dass ein C ++ - Compiler eine andere Zeichencodierung verwendet. Die Realität ist jedoch, dass Sie mit Sicherheit keine Plattform finden werden, auf der dieser Code nicht funktioniert. Dies ist besonders wichtig, da die neuen Codierungen für dominante Zeichen wie UTF-16 Unicode-basiert sind und Unicode alle ASCII-Werte für alle Zeichen im ASCII-Satz teilt. Der einzige Grund, warum dies implementation-defined ist, ist für sehr, sehr alte Legacy-Plattformen, die noch existierten, als dieser Teil des Standards geschrieben wurde - und Sie müssten Ihren Code grundlegend umgestalten, um auf jeder Plattform zu laufen, die kein ASCII ist / p>
Tags und Links c++ character-encoding char