Classes pour les données de type chaîne de caractères

Présentation

Cette page présente une vue d'ensemble des classes de chaînes de caractères dans Qt, en particulier la multitude de conteneurs de chaînes et la manière de les utiliser efficacement dans du code où les performances sont cruciales.

Les consignes d'utilisation efficace suivantes s'adressent aux développeurs expérimentés travaillant sur du code où les performances sont cruciales et qui comporte un traitement considérable de chaînes de caractères. Il s'agit, par exemple, d'un analyseur syntaxique ou d'un générateur de fichiers texte. En règle générale, ` QString ` peut être utilisé partout et fonctionnera correctement. Il fournit également des API permettant de gérer plusieurs encodages (par exemple ` QString::fromLatin1()`). Pour de nombreuses applications, et en particulier lorsque le traitement des chaînes de caractères ne joue qu’un rôle insignifiant en termes de performances, ` QString ` constituera une solution simple et suffisante. Certaines fonctions Qt renvoient un ` QStringView`. Celui-ci peut être converti en ` QString ` à l’aide de ` QStringView::toString()` si nécessaire.

Conseils utiles

Les trois règles suivantes améliorent considérablement la gestion des chaînes de caractères sans trop augmenter la complexité. Suivez ces règles pour obtenir des performances quasi optimales dans la plupart des cas. Les deux premières règles concernent l’encodage des littéraux de chaîne et leur marquage dans le code source. La troisième règle concerne les copies profondes lors de l’utilisation de parties d’une chaîne.

• Toutes les chaînes ne contenant que des caractères ASCII (par exemple, les messages de journal) peuvent être encodées en Latin-1. Utilisez la fonction string literal "foo"_L1 . Sans ce suffixe, les littéraux de chaîne dans le code source sont supposés être encodés en UTF-8 et leur traitement sera plus lent. En règle générale, essayez d’utiliser l’encodage le plus compact, qui est souvent Latin-1.
• Les chaînes visibles par l’utilisateur sont généralement traduites et donc transmises via la fonction QObject::tr(). Cette fonction prend une chaîne littérale (tableau de caractères const) et renvoie une chaîne QString avec un encodage UTF-16, comme l’exigent tous les éléments de l’interface utilisateur. Si l’infrastructure de traduction n’est pas utilisée, vous devez utiliser l’encodage UTF-16 dans l’ensemble de l’application. Utilisez la chaîne littérale u"foo" pour créer des chaînes littérales UTF-16 ou la chaîne littérale spécifique à Qt XML u"foo"_s pour créer directement un objet QString.
• Lors du traitement de parties d’un QString, au lieu de copier chaque partie dans son propre objet QString, créez plutôt des objets QStringView. Ceux-ci peuvent être reconvertis en QString à l’aide de QStringView::toString(), mais évitez de le faire autant que possible. Si des fonctions renvoient des QStringView, il est plus efficace de continuer à travailler avec cette classe, si possible. L’API est similaire à celle d’une constante QString.

Utilisation efficace

Pour utiliser efficacement les classes de chaînes, il convient de comprendre les trois concepts suivants :

• Encodage
• Conteneurs propriétaires et non propriétaires
• Littéraux

Encodage

En matière d'encodage, Qt prend en charge les formats UTF-16, UTF-8, Latin-1 (ISO 8859-1) et US-ASCII (qui est le sous-ensemble commun de Latin-1 et UTF-8) sous une forme ou une autre.

• Latin-1 est un encodage de caractères qui utilise un seul octet par caractère, ce qui en fait l'encodage le plus efficace mais aussi le plus limité.
• L'UTF-8 est un encodage de caractères à longueur variable qui encode tous les caractères en utilisant entre un et quatre octets. Il est rétrocompatible avec l'US-ASCII et constitue l'encodage courant pour le code source et les fichiers similaires. Qt part du principe que le code source est encodé en UTF-8.
• UTF-16 est un encodage à longueur variable qui utilise deux ou quatre octets par caractère. C'est l'encodage couramment utilisé pour le texte visible par l'utilisateur dans Qt.

Pour plus d’informations, consultez la documentation relative à la prise en charge d’Unicode dans Qt.

D'autres encodages sont pris en charge sous la forme de fonctions uniques telles que ` QString::fromUcs4()` ou via les classes ` QStringConverter `. De plus, Qt fournit un conteneur de données indépendant de l'encodage, ` QByteArray`, particulièrement adapté au stockage de données binaires. ` QAnyStringView ` garde en mémoire l'encodage de la chaîne sous-jacente et peut ainsi offrir une vue sur des chaînes utilisant n'importe quelle norme d'encodage prise en charge.

La conversion entre encodages est coûteuse ; il convient donc de l’éviter si possible. D’un autre côté, un encodage plus compact, en particulier pour les littéraux de chaîne, peut réduire la taille binaire, ce qui peut améliorer les performances. Lorsque les littéraux de chaîne peuvent être exprimés en Latin-1, cela permet d’atteindre un bon compromis entre ces facteurs contradictoires, même si une conversion en UTF-16 s’avère nécessaire à un moment donné. Lorsqu’une chaîne Latin-1 doit être convertie en « QString », cette opération s’effectue de manière relativement efficace.

Fonctionnalités

Les classes de chaînes peuvent également être distinguées en fonction des fonctionnalités qu’elles prennent en charge. Une distinction majeure réside dans le fait qu’elles possèdent, et donc contrôlent, leurs données ou qu’elles se contentent de référencer des données stockées ailleurs. Les premières sont appelées « conteneurs propriétaires », les secondes « conteneurs non propriétaires » ou « vues ». Un type de conteneur non propriétaire enregistre généralement juste un pointeur vers le début des données et leur taille, ce qui le rend léger et peu coûteux, mais il ne reste valide que tant que les données sont disponibles. Une chaîne « propriétaire » gère la mémoire dans laquelle elle stocke ses données, garantissant ainsi que celles-ci restent disponibles pendant toute la durée de vie du conteneur ; toutefois, sa création et sa destruction entraînent les coûts liés à l’allocation et à la libération de mémoire. Les vues prennent généralement en charge un sous-ensemble des fonctions de la chaîne « propriétaire », sans offrir la possibilité de modifier les données sous-jacentes.

Par conséquent, les vues de chaînes sont particulièrement bien adaptées à la représentation de parties de chaînes plus longues, par exemple dans un analyseur syntaxique, tandis que les chaînes propriétaires conviennent mieux au stockage persistant, comme les membres d’une classe. Lorsqu’une fonction renvoie une chaîne qu’elle a construite, par exemple en combinant des fragments, elle doit renvoyer une chaîne « owning » ; mais lorsqu’une fonction renvoie une partie d’une chaîne stockée de manière persistante, une vue est généralement plus appropriée.

Notez que les conteneurs « owning » dans Qt partagent leurs données implicitement, ce qui signifie qu’il est également efficace de passer ou de renvoyer de grands conteneurs par valeur, bien que cela soit légèrement moins efficace que le passage par référence en raison du comptage des références. Si vous souhaitez tirer parti du mécanisme de partage implicite des données des classes Qt, vous devez passer la chaîne sous la forme d’un conteneur propriétaire ou d’une référence à celui-ci. La conversion en vue et inversement créera toujours une copie supplémentaire des données.

Enfin, Qt fournit des classes pour les caractères individuels, les listes de chaînes de caractères et les comparateurs de chaînes. Ces classes sont disponibles pour la plupart des normes d’encodage prises en charge par Qt, à quelques exceptions près. Des fonctionnalités de plus haut niveau sont fournies par des classes spécialisées, telles que ` QLocale ` ou ` QTextBoundaryFinder`. Ces classes de haut niveau s’appuient généralement sur ` QString ` et son encodage UTF-16. Certaines classes sont des modèles et fonctionnent avec toutes les classes de chaînes disponibles.

Littéraux

La norme C++ fournit des littéraux de chaîne permettant de créer des chaînes au moment de la compilation. Il existe des littéraux de chaîne définis par le langage et des littéraux définis par Qt, appelés « littéraux définis par l’utilisateur ». Un littéral de chaîne défini par le C++ est placé entre guillemets doubles et peut comporter un préfixe indiquant au compilateur comment interpréter son contenu. Pour Qt, le littéral de chaîne UTF-16 u"foo" est le plus important. Il crée une chaîne encodée en UTF-16 lors de la compilation, ce qui évite d’avoir à effectuer une conversion à partir d’un autre encodage lors de l’exécution. Les objets ` QStringView ` peuvent être créés facilement et efficacement à partir de ce littéral ; ils peuvent donc être transmis à des fonctions acceptant un argument de type ` QStringView ` (ou, par conséquent, un ` QAnyStringView`).

Les littéraux définis par l’utilisateur ont la même forme que ceux définis par le C++, mais comportent un suffixe après la guillemet de fermeture. L’encodage reste déterminé par le préfixe, mais le littéral résultant est utilisé pour construire un objet d’un type défini par l’utilisateur. Qt définit donc ces littéraux pour certains de ses propres types de chaînes : u"foo"_s pour QString, "foo"_L1 pour QLatin1StringView et u"foo"_ba pour QByteArray. Ceux-ci sont fournis à l’aide de la fonction StringLiterals Namespace. Un littéral de chaîne C++ standard "foo" sera interprété comme étant en UTF-8 et la conversion vers QString, et donc vers UTF-16, sera coûteuse en ressources. Lorsque vous avez des littéraux de chaîne en ASCII simple, utilisez ` "foo"_L1 ` pour les interpréter en Latin-1, ce qui vous permettra de bénéficier des divers avantages décrits ci-dessus.

Classes de chaînes de caractères de base

Le tableau suivant donne un aperçu des classes de chaînes de caractères de base pour les différentes normes d’encodage de texte.

Certaines des entrées manquantes peuvent être remplacées par des types C++ intégrés ou issus de la bibliothèque standard : une chaîne codée en Latin-1 ou UTF-8 peut être de type ` std::string ` ou n'importe quel tableau de caractères de 8 bits de type ` char `. ` QStringView ` peut également faire référence à n'importe quel tableau de caractères de 16 bits, tel que `std::u16string` ou `std::wstring` sur certaines plateformes.

QStringList QByteArrayView QLatin1StringMatcher QByteArrayMatcherLes comparateurs disposent également de versions statiques créées lors de la compilation, QStaticLatin1StringMatcher et QStaticByteArrayMatcher.

À noter également :

• QStringLiteral est une macro identique à ` u"foo"_s ` et disponible sans le préfixe ` StringLiterals Namespace`. Il est préférable d’utiliser le littéral de chaîne moderne.
• QLatin1String est un synonyme de ` QLatin1StringView ` et existe à des fins de compatibilité ascendante. Il ne s’agit pas d’une chaîne de caractères « propriétaire » et cette fonction pourrait être supprimée dans les prochaines versions.
• QAnyStringView fournit une vue d’une chaîne dans l’un des trois encodages pris en charge. L’encodage est stocké avec la référence aux données. Cette classe est particulièrement adaptée à la création d’interfaces acceptant un large éventail de types de chaînes et d’encodages. Contrairement à d’autres classes, aucun traitement n’est effectué directement sur ` QAnyStringView `. Le traitement s’effectue sur l’ QLatin1StringView, QUtf8StringView ou QStringView sous-jacente, dans l’encodage correspondant. Utilisez QAnyStringView::visit() pour effectuer la même opération dans vos propres fonctions qui prennent cette classe en argument.
• Un QLatin1StringView contenant des caractères non ASCII n’est pas simple à construire dans un fichier de code source encodé en UTF-8 et nécessite un traitement particulier ; consultez la documentation de QLatin1StringView.
• QStringRef est une référence à une partie d’une « QString », disponible dans le module Qt5Compat à des fins de compatibilité ascendante. Elle doit être remplacée par QStringView.

Classes de haut niveau liées aux chaînes de caractères

D'autres classes de haut niveau offrant des fonctionnalités supplémentaires fonctionnent principalement avec ` QString ` et donc en UTF-16. Il s'agit de :

• QRegularExpression, QRegularExpressionMatch et QRegularExpressionMatchIterator pour la gestion des correspondances de motifs et des expressions régulières.
• QLocale pour convertir des nombres et des données en chaînes de caractères et inversement, d’une manière adaptée à la langue et à la culture de l’utilisateur.
• QCollator et QCollatorSortKey pour comparer des chaînes de caractères en fonction de la langue, de l’écriture ou du territoire de l’utilisateur.
• QTextBoundaryFinder pour couper le texte en vue de sa composition, conformément aux règles Unicode.
• QStringBuilder, une classe interne qui améliore considérablement les performances des concaténations de chaînes avec l’opérateur +; voir la documentation de QString.

Certaines classes sont des modèles ou disposent d’une API flexible et fonctionnent avec diverses classes de chaînes de caractères. Il s’agit notamment de

• QTextStream pour effectuer un flux vers ` QIODevice`, ` QByteArray ` ou QString
• QStringTokenizer pour diviser des chaînes

Quelle classe de chaînes utiliser ?

La règle générale concernant l’utilisation des classes de chaînes de caractères est la suivante :

• Évitez les copies et les allocations de mémoire,
• Évitez les conversions d'encodage, et
• Choisissez l'encodage le plus compact.

Qt offre de nombreuses fonctionnalités permettant d’éviter les allocations de mémoire. La plupart des conteneurs Qt utilisent le partage implicite de leurs données. Pour que le partage implicite fonctionne, il doit exister une chaîne ininterrompue d’instances de la même classe : passer de QString à QStringView puis revenir en arrière entraînera la création de deux QStrings qui ne partagent pas leurs données. Par conséquent, les fonctions doivent transmettre leurs données sous forme d’ QString s (les valeurs comme les références conviennent). Il n’est pas possible d’extraire des parties d’une chaîne de caractères avec le partage implicite des données. Pour utiliser des parties d’une chaîne plus longue, recourez aux vues de chaîne, une forme explicite de partage des données.

Les conversions entre encodages peuvent être réduites en s’en tenant à un encodage spécifique. Les données reçues, par exemple en UTF-8, sont mieux stockées et traitées en UTF-8 si aucune conversion vers un autre encodage n’est nécessaire. Les comparaisons entre chaînes de caractères du même encodage sont plus rapides, tout comme la plupart des autres opérations. Si des chaînes d’un certain encodage sont souvent comparées ou converties vers un autre encodage, il peut être avantageux de les convertir et de les stocker une seule fois. Certaines opérations proposent de nombreuses surcharges (ou une surcharge de type « QAnyStringView ») pour prendre en charge divers types de chaînes et encodages ; elles devraient constituer le deuxième choix pour optimiser les performances, si l’utilisation d’un encodage unique n’est pas envisageable. Les conversions d’encodage explicites avant l’appel d’une fonction ne doivent être utilisées qu’en dernier recours, lorsqu’aucune autre option n’est disponible. Latin-1 est un encodage très simple et les opérations entre Latin-1 et tout autre encodage sont presque aussi efficaces que les opérations entre encodages identiques.

L’encodage le plus efficace (du plus efficace au moins efficace : Latin-1, UTF-8, UTF-16) doit être choisi lorsqu’aucune autre contrainte ne détermine l’encodage. Pour la gestion des erreurs et la journalisation, l’ QLatin1StringView est généralement suffisant. Les chaînes visibles par l’utilisateur dans Qt sont toujours de type QString et, à ce titre, encodées en UTF-16. Il est donc plus efficace d’utiliser QStrings, QStringViews et QStringLiterals tout au long du cycle de vie d’une chaîne visible par l’utilisateur. La fonction QObject::tr() fournit l’encodage et le type corrects. QByteArray doit être utilisé si l’encodage n’a pas d’importance, par exemple pour stocker des données binaires, ou si l’encodage est inconnu.

Classe String pour la création d’API

Variables membres

Les variables membres doivent être d’un type propriétaire dans la quasi-totalité des cas. Les vues ne peuvent être utilisées comme variables membres que si la durée de vie de la chaîne propriétaire référencée est garantie de dépasser celle de l’objet.

Arguments de fonction

Les arguments de fonction doivent être, dans la plupart des cas, des vues de chaîne de caractères avec un encodage approprié. ` QAnyStringView ` peut être utilisé comme paramètre pour prendre en charge plusieurs encodages, et ` QAnyStringView::visit()` peut être utilisé en interne pour dériver des fonctions spécifiques à chaque encodage. Si la fonction est limitée à un seul encodage, il convient d’utiliser ` QLatin1StringView`, ` QUtf8StringView`, ` QStringView ` ou ` QByteArrayView `.

Si la fonction enregistre l’argument dans une chaîne de caractères « owning » (généralement une fonction setter), il est plus efficace d’utiliser cette même chaîne « owning » comme argument de la fonction afin de tirer parti de la fonctionnalité de partage implicite des données de Qt. La chaîne « owning » peut être transmise sous forme de référence de type ` const `. La surcharge de fonctions avec plusieurs types de chaînes « owning » et « non-owning » peut entraîner une ambiguïté de surcharge et doit être évitée. Les types de chaînes « owning » dans Qt peuvent être automatiquement convertis en leur version « non-owning » ou en « QAnyStringView ».

Valeurs de retour

Les chaînes temporaires doivent être renvoyées sous forme de chaîne « owning », généralement de type ` QString`. Si la chaîne renvoyée est connue à la compilation, utilisez ` u"foo"_s ` pour construire la structure ` QString ` à la compilation. Si des chaînes de caractères « owning » existantes (par exemple QString) sont renvoyées intégralement par une fonction (par exemple une fonction getter), il est plus efficace de les renvoyer par référence. Elles peuvent également être renvoyées par valeur afin de permettre le renvoi d’une chaîne temporaire à l’avenir. L’utilisation du partage implicite par Qt évite l’impact sur les performances lié à l’allocation et à la copie lors du renvoi par valeur.

Des parties de chaînes existantes peuvent être renvoyées efficacement à l’aide d’une vue de chaîne (string view) avec l’encodage approprié ; pour un exemple, voir QRegularExpressionMatch::capturedView() qui renvoie un objet QStringView.

Classe String pour l’utilisation de l’API

Pour utiliser efficacement une API Qt, vous devez essayer de faire correspondre les types d’arguments des fonctions. Si votre choix est limité, Qt effectuera diverses conversions : les chaînes « owning » sont implicitement converties en chaînes « non-owning », tandis que les chaînes « non-owning » peuvent créer leurs équivalents « owning » ; voir par exemple QStringView::toString(). Les conversions d’encodage sont effectuées implicitement dans de nombreux cas, mais cela doit être évité si possible. Pour éviter toute conversion implicite accidentelle à partir de l’UTF-8, vous pouvez activer la macro QT_NO_CAST_FROM_ASCII.

Si vous devez assembler une chaîne de caractères lors de l'exécution avant de la transmettre à une fonction, vous aurez besoin d'une chaîne de caractères « owning » et donc de QString. Si l'argument de la fonction est de type QStringView ou QAnyStringView, il sera implicitement converti.

Si la chaîne est connue à la compilation, il est possible de l'optimiser. Si la fonction accepte une chaîne de type « QString », vous devez la créer à l’aide de « u"foo"_s » ou de la macro « QStringLiteral ». Si la fonction attend une chaîne de type « QStringView », il est préférable de la construire à l’aide d’un littéral de chaîne UTF-16 ordinaire « u"foo" » ; si une chaîne de type « QLatin1StringView » est attendue, construisez-la à l’aide de « "foo"_L1 ». Si vous avez le choix entre les deux, par exemple si la fonction attend une chaîne de type « QAnyStringView », utilisez l’encodage le plus restreint, généralement Latin-1.

Liste de toutes les classes liées aux chaînes de caractères