Was ist die Idee hinter ^ = 32, die Kleinbuchstaben in Großbuchstaben umwandelt und umgekehrt?

Ich habe ein Problem mit Codeforces gelöst. Normalerweise überprüfe ich zuerst, ob das Zeichen ein oberer oder unterer englischer Buchstabe ist, subtrahiere oder addiere es 32, um es in den entsprechenden Buchstaben umzuwandeln. Aber ich habe jemanden gefunden, ^= 32der das Gleiche tut. Hier ist es:

char foo = 'a';
foo ^= 32;
char bar = 'A';
bar ^= 32;
cout << foo << ' ' << bar << '\n'; // foo is A, and bar is a

Ich habe nach einer Erklärung dafür gesucht und es nicht herausgefunden. Warum funktioniert das so?

Werfen wir einen Blick auf die ASCII-Codetabelle in Binärform.

A 1000001    a 1100001
B 1000010    b 1100010
C 1000011    c 1100011
...
Z 1011010    z 1111010

Und 32 ist 0100000der einzige Unterschied zwischen Klein- und Großbuchstaben. Wenn Sie dieses Bit umschalten, wird der Fall eines Buchstabens umgeschaltet.

Dies nutzt die Tatsache, dass ASCII-Werte von wirklich klugen Leuten gewählt wurden.

foo ^= 32;

Dadurch wird das sechstniedrigste Bit ¹ von foo(das Großbuchstaben-Flag von ASCII) umgedreht, wodurch ein ASCII-Großbuchstabe in einen Kleinbuchstaben umgewandelt wird und umgekehrt .

+---+------------+------------+
|   | Upper case | Lower case |  32 is 00100000
+---+------------+------------+
| A | 01000001   | 01100001   |
| B | 01000010   | 01100010   |
|            ...              |
| Z | 01011010   | 01111010   |
+---+------------+------------+

Beispiel

'A' ^ 32

    01000001 'A'
XOR 00100000 32
------------
    01100001 'a'

Und durch Eigentum von XOR , 'a' ^ 32 == 'A'.

Beachten

C ++ ist nicht erforderlich, um ASCII zur Darstellung von Zeichen zu verwenden. Eine andere Variante ist EBCDIC . Dieser Trick funktioniert nur auf ASCII-Plattformen. Eine tragbarere Lösung wäre die Verwendung von std::tolowerund std::touppermit dem angebotenen Bonus, um das Gebietsschema zu kennen (es löst jedoch nicht automatisch alle Ihre Probleme, siehe Kommentare):

bool case_incensitive_equal(char lhs, char rhs)
{
    return std::tolower(lhs, std::locale{}) == std::tolower(rhs, std::locale{}); // std::locale{} optional, enable locale-awarness
}

assert(case_incensitive_equal('A', 'a'));

¹⁾ Da 32 1 << 5(2 hoch 5) ist, wird das 6. Bit umgedreht (von 1 gezählt).

Lassen Sie mich sagen, dass dies - obwohl es klug erscheint - ein wirklich, wirklich dummer Hack ist. Wenn Ihnen dies 2019 jemand empfiehlt, schlagen Sie ihn. Schlagen Sie ihn so hart wie möglich.
Sie können dies natürlich in Ihrer eigenen Software tun, die Sie und niemand anderes verwendet, wenn Sie wissen, dass Sie sowieso nie eine andere Sprache als Englisch verwenden werden. Ansonsten nicht gehen.

Der Hack war vor 30-35 Jahren wohl "OK", als Computer nicht wirklich viel konnten, sondern Englisch in ASCII und vielleicht eine oder zwei wichtige europäische Sprachen. Aber ... nicht mehr so.

Der Hack funktioniert, weil US-lateinische Groß- und Kleinschreibung genau 0x20voneinander getrennt sind und in derselben Reihenfolge angezeigt werden, was nur ein kleiner Unterschied ist. Was in der Tat dieses bisschen Hack umschaltet.

Jetzt waren die Leute, die Codepages für Westeuropa und später das Unicode-Konsortium erstellten, klug genug, um dieses Schema für z. B. deutsche Umlaute und Vokale mit französischem Akzent beizubehalten. Nicht so für ß, die (bis jemand das Unicode-Konsortium 2017 überzeugte und ein großes Fake News-Printmagazin darüber schrieb und den Duden tatsächlich überzeugte - kein Kommentar dazu) nicht einmal als Versal existieren (verwandelt sich in SS) . Jetzt tut es existieren als versal, aber die beiden sind 0x1DBFPositionen auseinander, nicht 0x20.

Die Implementierer waren jedoch nicht rücksichtsvoll genug, um dies aufrechtzuerhalten. Wenn Sie beispielsweise Ihren Hack in einigen osteuropäischen Sprachen oder ähnlichem anwenden (ich würde nichts über Kyrillisch wissen), werden Sie eine böse Überraschung erleben. Alle diese "Beil" -Zeichen sind Beispiele dafür, Klein- und Großbuchstaben sind voneinander getrennt. Der Hack tut es also funktioniert dort nicht richtig.

Es gibt noch viel mehr zu beachten. Einige Zeichen werden beispielsweise nicht einfach von Klein- in Großbuchstaben umgewandelt (sie werden durch unterschiedliche Sequenzen ersetzt), oder sie können ihre Form ändern (was unterschiedliche Codepunkte erfordert).

Denken Sie nicht einmal darüber nach, was dieser Hack für Dinge wie Thai oder Chinesisch tun wird (es gibt Ihnen nur völligen Unsinn).

Das Speichern von ein paar hundert CPU-Zyklen hat sich vor 30 Jahren vielleicht sehr gelohnt, aber heutzutage gibt es wirklich keine Entschuldigung dafür, einen String richtig zu konvertieren. Es gibt Bibliotheksfunktionen zum Ausführen dieser nicht trivialen Aufgabe.
Die Zeit, die benötigt wird, um mehrere Dutzend Kilobyte Text richtig zu konvertieren, ist heutzutage vernachlässigbar.

Es funktioniert, weil der Unterschied zwischen 'a' und A 'in ASCII und abgeleiteten Codierungen zufällig 32 beträgt und 32 auch der Wert des sechsten Bits ist. Das Umdrehen des 6. Bits mit einem exklusiven ODER konvertiert somit zwischen oberem und unterem.

Höchstwahrscheinlich wird Ihre Implementierung des Zeichensatzes ASCII sein. Wenn wir uns die Tabelle ansehen:

Wir sehen, dass es einen Unterschied 32zwischen dem Wert einer Klein- und Großbuchstabenzahl gibt. Wenn wir dies tun ^= 32(was dem Umschalten des 6. niedrigstwertigen Bits entspricht), ändert sich daher zwischen einem Klein- und einem Großbuchstaben.

Beachten Sie, dass es mit allen Symbolen funktioniert, nicht nur mit den Buchstaben. Es schaltet ein Zeichen mit dem jeweiligen Zeichen um, wobei das 6. Bit unterschiedlich ist, was zu einem Zeichenpaar führt, das zwischen den Zeichen hin- und hergeschaltet wird. Für die Buchstaben bilden die jeweiligen Groß- / Kleinbuchstaben ein solches Paar. A NULwird sich in Spaceund umgekehrt ändern und @mit dem Backtick umschalten. Grundsätzlich wechselt jedes Zeichen in der ersten Spalte dieses Diagramms mit dem Zeichen eine Spalte weiter, und das Gleiche gilt für die dritte und vierte Spalte.

Ich würde diesen Hack jedoch nicht verwenden, da es keine Garantie dafür gibt, dass er auf jedem System funktioniert. Verwenden Sie stattdessen einfach toupper und tolower und Fragen wie isupper .

Hier gibt es viele gute Antworten, die beschreiben, wie dies funktioniert, aber warum es so funktioniert, ist die Verbesserung der Leistung. Bitweise Operationen sind schneller als die meisten anderen Operationen innerhalb eines Prozessors. Sie können schnell einen Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung durchführen, indem Sie einfach nicht auf das Bit schauen, das die Groß- und Kleinschreibung bestimmt, oder die Groß- / Kleinschreibung einfach ändern, indem Sie das Bit umdrehen (die Leute, die die ASCII-Tabelle entworfen haben, waren ziemlich schlau).

Offensichtlich ist dies aufgrund schnellerer Prozessoren und Unicode nicht annähernd so wichtig wie 1960 (als die Arbeit an ASCII begann), aber es gibt immer noch einige kostengünstige Prozessoren, die einen signifikanten Unterschied bewirken könnten solange Sie nur ASCII-Zeichen garantieren können.

https://en.wikipedia.org/wiki/Bitwise_operation

Bei einfachen kostengünstigen Prozessoren sind bitweise Operationen in der Regel wesentlich schneller als die Division, um ein Vielfaches schneller als die Multiplikation und manchmal erheblich schneller als die Addition.

HINWEIS: Ich würde aus verschiedenen Gründen (Lesbarkeit, Korrektheit, Portabilität usw.) die Verwendung von Standardbibliotheken für die Arbeit mit Zeichenfolgen empfehlen. Verwenden Sie Bit Flipping nur, wenn Sie die Leistung gemessen haben und dies Ihr Engpass ist.

So funktioniert ASCII, das ist alles.

Wenn Sie dies ausnutzen, geben Sie die Portabilität auf, da C ++ nicht auf ASCII als Codierung besteht.

Aus diesem Grund sind die Funktionen std::toupperund std::tolowerin der C ++ - Standardbibliothek implementiert - Sie sollten diese stattdessen verwenden.

Siehe die zweite Tabelle unter http://www.catb.org/esr/faqs/things-every-hacker-once-knew/#_ascii und die folgenden Hinweise, die unten wiedergegeben sind:

Der Control-Modifikator auf Ihrer Tastatur löscht im Wesentlichen die oberen drei Bits des von Ihnen eingegebenen Zeichens, belässt die unteren fünf und ordnet sie dem Bereich 0..31 zu. So bedeuten beispielsweise Strg-LEERTASTE, Strg-@ und Strg-`alle dasselbe: NUL.

Sehr alte Tastaturen verwendeten Shift, indem sie je nach Taste die 32- oder 16-Bit-Taste umschalteten. Aus diesem Grund ist die Beziehung zwischen Klein- und Großbuchstaben in ASCII so regelmäßig, und die Beziehung zwischen Zahlen und Symbolen und einigen Symbolpaaren ist regelmäßig, wenn Sie darauf blinzeln. Mit dem ASR-33, bei dem es sich um ein Terminal in Großbuchstaben handelte, konnten Sie sogar einige Satzzeichen generieren, für die es keine Tasten gab, indem Sie das 16-Bit-Format verschieben. So wurde beispielsweise Shift-K (0x4B) zu einem [(0x5B)

ASCII wurde so konzipiert, dass die Tasten shiftund und ctrlohne viel (oder vielleicht auch keine ctrl) Logik implementiert werden können -shift wahrscheinlich sind nur wenige Gates erforderlich. Es war wahrscheinlich mindestens so sinnvoll, das Drahtprotokoll zu speichern wie jede andere Zeichenkodierung (keine Softwarekonvertierung erforderlich).

Der verlinkte Artikel auch erklärt , viele fremde Hacker Konventionen wie And control H does a single character and is an old^H^H^H^H^H classic joke.( gefunden hier ).

Beim Xoring mit 32 (00100000 in Binär) wird das sechste Bit (von rechts) gesetzt oder zurückgesetzt. Dies entspricht genau dem Addieren oder Subtrahieren von 32.

Die alphabetischen Bereiche in Klein- und Großbuchstaben %32überschreiten im ASCII-Codierungssystem keine "Ausrichtungsgrenze".

Aus diesem Grund ist Bit 0x20der einzige Unterschied zwischen den Groß- / Kleinbuchstaben desselben Buchstabens.

Wenn dies nicht der Fall wäre, müssten Sie addieren oder subtrahieren 0x20, nicht nur umschalten, und für einige Buchstaben würde es eine Ausführung geben, um andere höhere Bits umzudrehen. (Und es würde keine einzige Operation geben, die umschalten könnte, und es wäre schwieriger, zunächst nach alphabetischen Zeichen zu suchen, da Sie | = 0x20 nicht zwingen könnten, lcase zu erzwingen.)

Verwandte Nur-ASCII-Tricks: Sie können nach einem alphabetischen ASCII-Zeichen suchen, indem Sie Kleinbuchstaben mit erzwingen c |= 0x20und dann prüfen, ob (ohne Vorzeichen) c - 'a' <= ('z'-'a'). Also nur 3 Operationen: OR + SUB + CMP gegen eine Konstante 25. Natürlich wissen Compiler, wie (c>='a' && c<='z') man so etwas für Sie optimiert , also sollten Sie den c|=0x20Teil höchstens selbst erledigen . Es ist ziemlich unpraktisch, alle erforderlichen Castings selbst durchzuführen, insbesondere um standardmäßige Ganzzahl-Promotions für signierte zu umgehen int.

unsigned char lcase = y|0x20;
if (lcase - 'a' <= (unsigned)('z'-'a')) {   // lcase-'a' will wrap for characters below 'a'
    // c is alphabetic ASCII
}
// else it's not

Siehe auch Konvertieren einer Zeichenfolge in C ++ in Großbuchstaben (SIMD-Zeichenfolge)toupper für ASCII, wobei der Operand für XOR mithilfe dieser Prüfung maskiert wird.)

Außerdem erfahren Sie, wie Sie auf ein Zeichenarray zugreifen und Kleinbuchstaben in Großbuchstaben ändern und umgekehrt (C mit SIMD-Eigenheiten und skalarem x86-Asm-Fall-Flip für alphabetische ASCII-Zeichen, wobei andere unverändert bleiben).

Diese Tricks sind meistens nur nützlich, wenn Sie eine Textverarbeitung mit SIMD (z. B. SSE2 oder NEON) von Hand optimieren, nachdem Sie überprüft haben, ob bei keinem der chars in einem Vektor das High-Bit gesetzt ist. (Und daher ist keines der Bytes Teil einer Multi-Byte-UTF-8-Codierung für ein einzelnes Zeichen, die möglicherweise unterschiedliche Inversen in Groß- / Kleinbuchstaben aufweist.) Wenn Sie welche finden, können Sie für diesen 16-Byte-Block oder für den Rest der Zeichenfolge auf den Skalar zurückgreifen.

Es gibt sogar einige Gebietsschemas, in denen toupper()oder tolower()auf einigen Zeichen im ASCII-Bereich Zeichen außerhalb dieses Bereichs erzeugt werden, insbesondere auf Türkisch, wo I ↔ ı und İ ↔ i. In diesen Gebietsschemas benötigen Sie eine differenziertere Prüfung oder versuchen wahrscheinlich gar nicht, diese Optimierung zu verwenden.

In einigen Fällen dürfen Sie jedoch ASCII anstelle von UTF-8 annehmen, z. B. Unix-Dienstprogramme mit LANG=C(dem POSIX-Gebietsschema), nichten_CA.UTF-8 oder was auch immer.

Aber wenn Sie überprüfen können, ob es sicher ist, können Sie toupperZeichenfolgen mittlerer Länge viel schneller als toupper()in einer Schleife aufrufen (wie 5x), und zuletzt habe ich mit Boost 1.58 getestet , viel schneller als das, boost::to_upper_copy<char*, std::string>()was dynamic_castfür jeden Charakter dumm ist .