Klassen für Zeichenfolgendaten

Übersicht

Diese Seite bietet einen Überblick über Zeichenfolgenklassen in Qt, insbesondere über die Vielzahl an Zeichenfolgen-Containern und deren effiziente Verwendung in leistungskritischem Code.

Die folgenden Anleitungen zur effizienten Nutzung richten sich an erfahrene Entwickler, die an leistungskritischem Code arbeiten, der umfangreiche Zeichenfolgenverarbeitung beinhaltet. Dies sind beispielsweise Parser oder Textdateigeneratoren. Im Allgemeinen kann ` QString ` überall verwendet werden und liefert gute Ergebnisse. Es bietet zudem APIs für die Verarbeitung verschiedener Kodierungen (z. B. ` QString::fromLatin1()`). Für viele Anwendungen und insbesondere dann, wenn die Zeichenfolgenverarbeitung für die Leistung keine wesentliche Rolle spielt, ist ` QString ` eine einfache und ausreichende Lösung. Einige Qt-Funktionen geben ein ` QStringView` zurück. Dieses kann bei Bedarf mit ` QStringView::toString()` in ein ` QString ` umgewandelt werden.

Wichtige Tipps

Die folgenden drei Regeln verbessern die Zeichenfolgenverarbeitung erheblich, ohne die Komplexität allzu sehr zu erhöhen. Befolgen Sie diese Regeln, um in den meisten Fällen nahezu optimale Leistung zu erzielen. Die ersten beiden Regeln befassen sich mit der Kodierung von Zeichenfolgenliteralen und deren Kennzeichnung im Quellcode. Die dritte Regel befasst sich mit Deep-Copies bei der Verwendung von Teilen einer Zeichenfolge.

• Alle Zeichenfolgen, die ausschließlich ASCII-Zeichen enthalten (z. B. Protokollmeldungen), können mit Latin-1 kodiert werden. Verwenden Sie das Suffix „ string literal “ "foo"_L1. Ohne dieses Suffix wird davon ausgegangen, dass Zeichenfolgenliterale im Quellcode UTF-8-kodiert sind, was ihre Verarbeitung verlangsamt. Versuchen Sie generell, die kompakteste Kodierung zu verwenden, was in vielen Fällen Latin-1 ist.
• Für den Benutzer sichtbare Zeichenketten werden in der Regel übersetzt und daher über die Funktion „ QObject::tr()“ weitergeleitet. Diese Funktion nimmt ein Zeichenkettenliteral (const char-Array) entgegen und gibt ein „ QString “ mit UTF-16-Kodierung zurück, wie es von allen UI-Elementen gefordert wird. Wenn die Übersetzungsinfrastruktur nicht genutzt wird, solltest du in der gesamten Anwendung die UTF-16-Kodierung verwenden. Verwenden Sie das String-Literal ` u"foo" `, um UTF-16-String-Literale zu erstellen, oder das Qt-spezifische Literal ` u"foo"_s `, um direkt ein ` QString` zu erstellen.
• Wenn Sie Teile eines „ QString “ verarbeiten, sollten Sie, anstatt jeden Teil in ein eigenes „ QString “-Objekt zu kopieren, stattdessen „ QStringView “-Objekte erstellen. Diese können mit „ QStringView::toString()“ wieder in „ QString “ konvertiert werden, doch sollten Sie dies so weit wie möglich vermeiden. Wenn Funktionen „ QStringView “ zurückgeben, ist es am effizientesten, nach Möglichkeit weiterhin mit dieser Klasse zu arbeiten. Die API ähnelt einer Konstante „ QString “.

Effiziente Nutzung

Um String-Klassen effizient zu nutzen, sollte man die folgenden drei Konzepte verstehen:

• Kodierung
• Eigentümer- und Nicht-Eigentümer-Container
• Literale

Kodierung

Was die Kodierung betrifft, unterstützt Qt UTF-16, UTF-8, Latin-1 (ISO 8859-1) und US-ASCII (das ist die gemeinsame Teilmenge von Latin-1 und UTF-8) in der einen oder anderen Form.

• Latin-1 ist eine Zeichenkodierung, die ein einzelnes Byte pro Zeichen verwendet, was sie zur effizientesten, aber auch zur eingeschränktesten Kodierung macht.
• UTF-8 ist eine Zeichenkodierung mit variabler Länge, die alle Zeichen mit einem bis vier Bytes kodiert. Sie ist abwärtskompatibel zu US-ASCII und die gängige Kodierung für Quellcode und ähnliche Dateien. Qt geht davon aus, dass Quellcode in UTF-8 kodiert ist.
• UTF-16 ist eine Kodierung mit variabler Länge, die zwei oder vier Bytes pro Zeichen verwendet. Sie ist die gängige Kodierung für benutzersichtbaren Text in Qt.

Weitere Informationen finden Sie in den Informationen zur Unicode-Unterstützung in Qt.

Andere Kodierungen werden in Form einzelner Funktionen wie ` QString::fromUcs4()` oder der Klassen ` QStringConverter ` unterstützt. Darüber hinaus stellt Qt einen kodierungsunabhängigen Container für Daten bereit, ` QByteArray`, der sich gut für die Speicherung binärer Daten eignet. ` QAnyStringView ` verfolgt die Kodierung der zugrunde liegenden Zeichenkette und kann somit eine Ansicht auf Zeichenketten mit jedem der unterstützten Kodierungsstandards bereitstellen.

Die Konvertierung zwischen Kodierungen ist rechenintensiv und sollte daher nach Möglichkeit vermieden werden. Andererseits kann eine kompaktere Kodierung, insbesondere für String-Literale, die Binärgröße reduzieren, was die Leistung steigern kann. Wo Zeichenfolgenliterale in Latin-1 ausgedrückt werden können, stellt dies einen guten Kompromiss zwischen diesen konkurrierenden Faktoren dar, selbst wenn sie irgendwann in UTF-16 konvertiert werden müssen. Wenn eine Latin-1-Zeichenfolge in eine „ QString “ konvertiert werden muss, geschieht dies relativ effizient.

Funktionalität

String-Klassen lassen sich zudem anhand der von ihnen unterstützten Funktionalität unterscheiden. Ein wesentlicher Unterschied besteht darin, ob sie ihre Daten besitzen und somit kontrollieren oder lediglich auf an anderer Stelle gespeicherte Daten verweisen. Erstere werden als „owning containers“ ( besitzende Container) bezeichnet, letztere als „non-owning containers“ ( nicht besitzende Container) oder „views“ (Ansichten). Ein nicht-besitzender Containertyp speichert in der Regel lediglich einen Zeiger auf den Anfang der Daten und deren Größe, wodurch er ressourcenschonend und kostengünstig ist; er bleibt jedoch nur so lange gültig, wie die Daten verfügbar sind. Ein „Owning“-String verwaltet den Speicher, in dem er seine Daten ablegt, und stellt so sicher, dass die Daten während der gesamten Lebensdauer des Containers verfügbar bleiben; seine Erstellung und Löschung sind jedoch mit den Kosten für die Zuweisung und Freigabe von Speicher verbunden. Ansichten unterstützen in der Regel nur einen Teil der Funktionen des „Owning“-Strings, da ihnen die Möglichkeit fehlt, die zugrunde liegenden Daten zu ändern.

Daher eignen sich String-Views besonders gut zur Darstellung von Teilen größerer Strings, beispielsweise in einem Parser, während „Owning Strings“ sich gut für die persistente Speicherung eignen, wie etwa als Mitglieder einer Klasse. Wenn eine Funktion eine Zeichenkette zurückgibt, die sie selbst erstellt hat – beispielsweise durch das Zusammenfügen von Fragmenten –, muss sie eine „Owning“-Zeichenkette zurückgeben; gibt eine Funktion jedoch einen Teil einer dauerhaft gespeicherten Zeichenkette zurück, ist eine View in der Regel besser geeignet.

Beachten Sie, dass „Owning“-Container in Qt ihre Daten implizit gemeinsam nutzen, was bedeutet, dass es auch effizient ist, große Container per Wert zu übergeben oder zurückzugeben, obwohl dies aufgrund der Referenzzählung etwas weniger effizient ist als die Übergabe per Referenz. Wenn Sie den impliziten Datenfreigabemechanismus von Qt-Klassen nutzen möchten, müssen Sie die Zeichenkette als „owning“-Container oder als Referenz darauf übergeben. Die Konvertierung in eine Ansicht und zurück erzeugt immer eine zusätzliche Kopie der Daten.

Schließlich stellt Qt Klassen für einzelne Zeichen, Zeichenfolgenlisten und Zeichenfolgenabgleicher bereit. Diese Klassen sind für die meisten in Qt unterstützten Kodierungsstandards verfügbar, mit einigen Ausnahmen. Funktionalität auf höherer Ebene wird durch spezialisierte Klassen bereitgestellt, wie beispielsweise „ QLocale “ oder „ QTextBoundaryFinder “. Diese Klassen auf höherer Ebene stützen sich in der Regel auf „ QString “ und dessen UTF-16-Kodierung. Einige Klassen sind Vorlagen und funktionieren mit allen verfügbaren Zeichenfolgenklassen.

Literale

Der C++-Standard stellt Zeichenfolgenliterale zur Verfügung, um Zeichenfolgen zur Kompilierungszeit zu erstellen. Es gibt von der Sprache definierte Zeichenfolgenliterale und von Qt definierte Literale, sogenannte benutzerdefinierte Literale. Ein von C++ definiertes Zeichenfolgenliteral wird in doppelte Anführungszeichen gesetzt und kann ein Präfix haben, das dem Compiler mitteilt, wie er den Inhalt interpretieren soll. Für Qt ist das UTF-16-Zeichenfolgenliteral u"foo" das wichtigste. Es erzeugt zur Kompilierungszeit eine in UTF-16 kodierte Zeichenkette, wodurch die Notwendigkeit entfällt, zur Laufzeit von einer anderen Kodierung zu konvertieren. Aus einem solchen Literal lassen sich einfach und effizient „ QStringView “ bilden, sodass sie an Funktionen übergeben werden können, die ein „ QStringView “-Argument (oder folglich ein „ QAnyStringView “) akzeptieren.

u"foo"_s QString "foo"_L1 QLatin1StringView u"foo"_ba StringLiterals Namespace "foo" QString Benutzerdefinierte Literale haben dieselbe Form wie die von C++ definierten, fügen jedoch ein Suffix hinter dem schließenden Anführungszeichen hinzu. Die Kodierung wird weiterhin durch das Präfix bestimmt, doch das resultierende Literal wird zur Erstellung eines Objekts eines benutzerdefinierten Typs verwendet. QByteArray Wenn Sie Zeichenfolgenliterale im reinen ASCII haben, verwenden Sie „ "foo"_L1 “, um sie als Latin-1 zu interpretieren, wodurch Sie die verschiedenen oben beschriebenen Vorteile nutzen können.

Grundlegende String-Klassen

Die folgende Tabelle gibt einen Überblick über grundlegende String-Klassen für die verschiedenen Standards der Textkodierung.

Einige der fehlenden Einträge können durch integrierte und in der Standardbibliothek enthaltene C++-Typen ersetzt werden: Eine Latin-1- oder UTF-8-kodierte Zeichenkette im Besitz des Objekts kann ein ` std::string ` oder ein beliebiges 8-Bit- char -Array sein. ` QStringView ` kann auch auf beliebige 16-Bit-Zeichen-Arrays verweisen, wie beispielsweise `std::u16string` oder `std::wstring` auf einigen Plattformen.

Qt stellt außerdem spezielle Listen für einige dieser Typen bereit, nämlich „ QStringList “ und „ QByteArrayView “, sowie Matcher wie „ QLatin1StringMatcher “ und „ QByteArrayMatcher “. Die Matcher verfügen zudem über statische Versionen, die zur Kompilierungszeit erstellt werden: „ QStaticLatin1StringMatcher “ und „ QStaticByteArrayMatcher “.

Außerdem ist zu beachten:

• QStringLiteral ist ein Makro, das mit „ u"foo"_s “ identisch ist und ohne den „ StringLiterals Namespace “ verfügbar ist. Vorzugsweise sollten Sie das moderne String-Literal verwenden.
• QLatin1String ist ein Synonym für ` QLatin1StringView ` und dient der Abwärtskompatibilität. Es handelt sich nicht um einen „eigentümenden“ String und könnte in zukünftigen Versionen entfernt werden.
• QAnyStringView bietet eine Ansicht für eine Zeichenkette mit einer der drei unterstützten Kodierungen. Die Kodierung wird zusammen mit dem Verweis auf die Daten gespeichert. Diese Klasse eignet sich gut zum Erstellen von Schnittstellen, die ein breites Spektrum an Zeichenkettentypen und Kodierungen akzeptieren. Im Gegensatz zu anderen Klassen wird keine Verarbeitung direkt an ` QAnyStringView ` durchgeführt. Die Verarbeitung erfolgt auf dem zugrunde liegenden ` QLatin1StringView`, ` QUtf8StringView ` oder ` QStringView ` in der jeweiligen Kodierung. Verwenden Sie ` QAnyStringView::visit()`, um dasselbe in Ihren eigenen Funktionen zu erreichen, die diese Klasse als Argument entgegennehmen.
• Ein ` QLatin1StringView ` mit Nicht-ASCII-Zeichen lässt sich in einer UTF-8-kodierten Quellcode-Datei nicht ohne Weiteres erstellen und erfordert eine spezielle Behandlung; siehe die Dokumentation zu ` QLatin1StringView `.
• QStringRef ist ein Verweis auf einen Teil eines „ QString “, der im Modul „Qt5Compat“ aus Gründen der Abwärtskompatibilität verfügbar ist. Er sollte durch „ QStringView “ ersetzt werden.

Übergeordnete Klassen im Zusammenhang mit Zeichenketten

Weitere übergeordnete Klassen, die zusätzliche Funktionen bereitstellen, arbeiten größtenteils mit ` QString ` und somit mit UTF-16. Dazu gehören:

• QRegularExpression, ` QRegularExpressionMatch ` und ` QRegularExpressionMatchIterator ` für die Arbeit mit Musterabgleich und regulären Ausdrücken.
• QLocale zur Konvertierung von Zahlen und Daten in und aus Zeichenfolgen in einer Weise, die der Sprache und Kultur des Benutzers entspricht.
• QCollator sowie ` QCollatorSortKey `, um Zeichenfolgen unter Berücksichtigung der Sprache, des Schriftsystems oder der Region des Benutzers zu vergleichen.
• QTextBoundaryFinder um Text gemäß den Unicode-Regeln für den Satz vorzubereiten.
• QStringBuilder, eine interne Klasse, die die Leistung von Zeichenfolgenverkettungen mit dem Operator „ + “ erheblich verbessert; siehe die Dokumentation zu „ QString “.

Einige Klassen sind Vorlagen oder verfügen über eine flexible API und arbeiten mit verschiedenen Zeichenfolgenklassen zusammen. Dazu gehören

• QTextStream zum Einlesen in „ QIODevice “, „ QByteArray “ oder QString
• QStringTokenizer zum Aufteilen von Zeichenketten

Welche Zeichenfolgenklasse soll verwendet werden?

Die allgemeine Richtlinie für die Verwendung von Zeichenfolgenklassen lautet:

• Vermeiden Sie Kopiervorgänge und Speicherzuweisungen,
• Vermeiden Sie Kodierungsumwandlungen und
• Wählen Sie die kompakteste Kodierung.

Qt bietet zahlreiche Funktionen, um Speicherzuweisungen zu vermeiden. Die meisten Qt-Container nutzen die implizite gemeinsame Nutzung ihrer Daten. Damit die implizite gemeinsame Nutzung funktioniert, muss eine ununterbrochene Kette derselben Klasse vorhanden sein – eine Konvertierung von „ QString “ zu „ QStringView “ und zurück führt zu zwei „ QStrings “, die ihre Daten nicht gemeinsam nutzen. Daher müssen Funktionen ihre Daten als „ QString “ übergeben (sowohl Werte als auch Referenzen sind zulässig). Das Extrahieren von Teilen einer Zeichenkette ist bei impliziter Datenfreigabe nicht möglich. Um Teile einer längeren Zeichenkette zu verwenden, nutzen Sie „String-Views“, eine explizite Form der Datenfreigabe.

Konvertierungen zwischen Kodierungen lassen sich reduzieren, indem man sich an eine bestimmte Kodierung hält. Daten, die beispielsweise in UTF-8 empfangen werden, sollten am besten in UTF-8 gespeichert und verarbeitet werden, sofern keine Konvertierung in eine andere Kodierung erforderlich ist. Vergleiche zwischen Zeichenketten derselben Kodierung sind am schnellsten, und dasselbe gilt für die meisten anderen Operationen. Wenn Zeichenketten einer bestimmten Kodierung häufig verglichen oder in eine andere Kodierung konvertiert werden, kann es vorteilhaft sein, sie einmalig zu konvertieren und zu speichern. Einige Operationen bieten zahlreiche Überladungen (oder eine „ QAnyStringView “-Überladung) für verschiedene Zeichenkettentypen und Kodierungen; diese sollten zur Leistungsoptimierung die zweite Wahl sein, wenn die Verwendung derselben Kodierung nicht möglich ist. Explizite Kodierungsumwandlungen vor dem Aufruf einer Funktion sollten nur als letzter Ausweg dienen, wenn keine andere Option zur Verfügung steht. Latin-1 ist eine sehr einfache Kodierung, und Operationen zwischen Latin-1 und jeder anderen Kodierung sind fast genauso effizient wie Operationen innerhalb derselben Kodierung.

Die effizienteste Kodierung (von der effizientesten zur am wenigsten effizienten: Latin-1, UTF-8, UTF-16) sollte gewählt werden, wenn keine anderen Einschränkungen die Kodierung bestimmen. Für die Fehlerbehandlung und Protokollierung ist „ QLatin1StringView “ in der Regel ausreichend. Für den Benutzer sichtbare Zeichenfolgen in Qt sind immer vom Typ „ QString “ und somit UTF-16-kodiert. Daher ist es am effektivsten, während der gesamten Lebensdauer einer für den Benutzer sichtbaren Zeichenkette QStrings, QStringViews und QStringLiterals zu verwenden. Die Funktion QObject::tr() liefert die korrekte Kodierung und den korrekten Typ. QByteArray sollte verwendet werden, wenn die Kodierung keine Rolle spielt, beispielsweise zum Speichern von Binärdaten, oder wenn die Kodierung unbekannt ist.

String-Klasse zum Erstellen einer API

Mitgliedsvariablen

Mitgliedsvariablen sollten in fast allen Fällen vom Typ des besitzenden Strings sein. „Views“ dürfen nur dann als Mitgliedsvariablen verwendet werden, wenn garantiert ist, dass die Lebensdauer des referenzierten besitzenden Strings die Lebensdauer des Objekts übersteigt.

Funktionsargumente

Funktionsargumente sollten in den meisten Fällen String-Views mit einer geeigneten Kodierung sein. ` QAnyStringView ` kann als Parameter verwendet werden, um mehr als eine Kodierung zu unterstützen, und ` QAnyStringView::visit()` kann intern verwendet werden, um in kodierungsspezifische Funktionen abzuzweigen. Wenn die Funktion auf eine einzige Kodierung beschränkt ist, sollten ` QLatin1StringView`, ` QUtf8StringView`, ` QStringView ` oder ` QByteArrayView ` verwendet werden.

Wenn die Funktion das Argument in einem „owning“-String speichert (in der Regel eine Setter-Funktion), ist es am effizientesten, denselben „owning“-String als Funktionsargument zu verwenden, um die implizite Datenfreigabefunktion von Qt zu nutzen. Der „owning“-String kann als const -Referenz übergeben werden. Das Überladen von Funktionen mit mehreren „owning“- und „non-owning“-Zeichenkettentypen kann zu Mehrdeutigkeiten bei der Überladung führen und sollte vermieden werden. „Owning“-Zeichenkettentypen in Qt können automatisch in ihre „non-owning“-Version oder in „ QAnyStringView “ konvertiert werden.

Rückgabewerte

Temporäre Zeichenfolgen müssen als „owning“-Zeichenfolge zurückgegeben werden, in der Regel als ` QString`. Ist die zurückgegebene Zeichenfolge zur Kompilierungszeit bekannt, verwenden Sie ` u"foo"_s `, um die Struktur ` QString ` zur Kompilierungszeit zu erstellen. Wenn vorhandene „Owning Strings“ (z. B. QString) vollständig aus einer Funktion zurückgegeben werden (z. B. einer Getter-Funktion), ist es am effizientesten, sie per Referenz zurückzugeben. Sie können auch per Wert zurückgegeben werden, um in Zukunft die Rückgabe einer temporären Zeichenkette zu ermöglichen. Durch die Verwendung von implizitem Sharing in Qt werden die Leistungseinbußen durch Zuweisung und Kopieren bei der Rückgabe per Wert vermieden.

Teile bestehender Zeichenfolgen können effizient mit einer String-View der entsprechenden Kodierung zurückgegeben werden; ein Beispiel hierfür ist QRegularExpressionMatch::capturedView(), das ein ` QStringView` zurückgibt.

String-Klasse zur Nutzung der API

Um eine Qt-API effizient zu nutzen, sollten Sie versuchen, die Typen der Funktionsargumente anzupassen. Wenn Ihre Auswahlmöglichkeiten begrenzt sind, führt Qt verschiedene Konvertierungen durch: „Owning“-Zeichenketten werden implizit in „Non-Owning“-Zeichenketten konvertiert, „Non-Owning“-Zeichenketten können ihre entsprechenden „Owning“-Entsprechungen erzeugen; siehe zum Beispiel QStringView::toString(). Kodierungsumwandlungen werden in vielen Fällen implizit durchgeführt, dies sollte jedoch nach Möglichkeit vermieden werden. Um eine versehentliche implizite Umwandlung von UTF-8 zu vermeiden, können Sie das Makro QT_NO_CAST_FROM_ASCII aktivieren.

Wenn Sie eine Zeichenkette zur Laufzeit zusammenstellen müssen, bevor Sie sie an eine Funktion übergeben, benötigen Sie eine „Owning“-Zeichenkette und somit „ QString “. Wenn das Funktionsargument „ QStringView “ oder „ QAnyStringView “ lautet, wird es implizit konvertiert.

Ist die Zeichenkette zur Kompilierungszeit bekannt, besteht Optimierungsspielraum. Wenn die Funktion einen „ QString “ akzeptiert, sollten Sie diesen mit „ u"foo"_s “ oder dem Makro „ QStringLiteral “ erstellen. Wenn die Funktion einen „ QStringView “ erwartet, wird dieser am besten mit einem gewöhnlichen UTF-16-Zeichenfolgenliteral „ u"foo" “ erstellt; wenn ein „ QLatin1StringView “ erwartet wird, erstellen Sie ihn mit „ "foo"_L1 “. Wenn Sie die Wahl zwischen beiden haben, beispielsweise wenn die Funktion „ QAnyStringView “ erwartet, verwenden Sie die kompakteste Kodierung, in der Regel Latin-1.

Liste aller Klassen im Zusammenhang mit Zeichenketten