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

Vue d'ensemble

Cette page donne une vue d'ensemble des classes de chaînes de caractères dans Qt, en particulier la grande quantité de conteneurs de chaînes de caractères et la manière de les utiliser efficacement dans un code dont les performances sont critiques.

Les instructions suivantes pour une utilisation efficace sont destinées aux développeurs expérimentés travaillant sur du code à performances critiques qui contient des quantités considérables de traitement de chaînes de caractères. Il peut s'agir, 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 parfaitement. Il fournit également des API pour gérer plusieurs encodages (par exemple QString::fromLatin1()). Pour de nombreuses applications, et en particulier lorsque le traitement des chaînes de caractères joue un rôle insignifiant en termes de performances, QString sera une solution simple et suffisante. Certaines fonctions de Qt XML renvoient un code QStringView qui peut être converti en code QString avec 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 presque optimales dans la plupart des cas. Les deux premières règles concernent le codage des chaînes littérales 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 qui ne contiennent que des caractères ASCII (par exemple les messages de journal) peuvent être codées en Latin-1. Utilisez le suffixe string literal "foo"_L1 . Sans ce suffixe, les chaînes littérales dans le code source sont supposées être encodées en UTF-8 et leur traitement sera plus lent. En règle générale, essayez d'utiliser l'encodage le plus strict, c'est-à-dire le Latin-1 dans la plupart des cas.
• Les chaînes visibles par l'utilisateur sont généralement traduites et passent donc par la fonction QObject::tr(). Cette fonction prend un littéral de chaîne (tableau de caractères constants) et renvoie une adresse QString avec un encodage UTF-16 tel qu'exigé par tous les éléments de l'interface utilisateur. Si l'infrastructure de traduction n'est pas utilisée, vous devez utiliser le codage UTF-16 dans l'ensemble de l'application. Utilisez le littéral de chaîne u"foo" pour créer des littéraux de chaîne UTF-16 ou le littéral spécifique à Qt XML u"foo"_s pour créer directement un QString.
• Lorsque vous traitez des parties d'un document 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 autant que possible de le faire. Si des fonctions renvoient QStringView, il est plus efficace de continuer à travailler avec cette classe, si possible. L'API est similaire à une constante QString.

Utilisation efficace

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

• Encodage
• Conteneurs propriétaires et non propriétaires
• les littéraux

Encodage

Qt supporte les encodages 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 codage de caractères qui utilise un seul octet par caractère, ce qui en fait le codage le plus efficace mais aussi le plus limité.
• UTF-8 est un encodage de caractères de longueur variable qui code tous les caractères en utilisant un à quatre octets. Il est rétrocompatible avec l'US-ASCII et c'est l'encodage commun pour le code source et les fichiers similaires. Qt suppose que le code source est encodé en UTF-8.
• UTF-16 est un encodage de longueur variable qui utilise deux ou quatre octets par caractère. C'est l'encodage commun pour le texte exposé par l'utilisateur dans Qt.

Voir les informations sur la prise en charge d'Unicode dans Qt pour plus d'informations.

D'autres encodages sont pris en charge sous la forme de fonctions simples comme QString::fromUcs4() ou de classes QStringConverter. En outre, Qt XML fournit un conteneur de données agnostique en matière d'encodage, QByteArray, qui est bien adapté au stockage de données binaires. QAnyStringView garde la trace de l'encodage de la chaîne sous-jacente et peut donc porter une vue sur les chaînes avec n'importe laquelle des normes d'encodage prises en charge.

La conversion d'un encodage à l'autre est coûteuse, il faut donc l'éviter si possible. D'un autre côté, un encodage plus compact, en particulier pour les chaînes littérales, peut réduire la taille des binaires, ce qui peut améliorer les performances. Lorsque les chaînes de caractères littérales peuvent être exprimées en Latin-1, elles constituent un bon compromis entre ces facteurs concurrents, même si elles doivent être converties en UTF-16 à un moment ou à un autre. Lorsqu'une chaîne en Latin-1 doit être convertie en QString, la conversion est relativement efficace.

Fonctionnalité

Les classes de chaînes de caractères se distinguent également par les fonctionnalités qu'elles prennent en charge. Une distinction majeure est de savoir si elles possèdent, et donc contrôlent, leurs données ou si elles font simplement référence à des données détenues ailleurs. Les premières sont appelées conteneurs propriétaires, les seconds conteneurs non propriétaires ou vues. Un type de conteneur non propriétaire se contente généralement d'enregistrer un pointeur sur 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 restent disponibles. Une chaîne propriétaire gère la mémoire dans laquelle elle stocke ses données, garantissant que les données restent disponibles pendant toute la durée de vie du conteneur, mais sa création et sa destruction entraînent des coûts d'allocation et de libération de la mémoire. Les vues prennent généralement en charge un sous-ensemble des fonctions de la chaîne propriétaire, sans possibilité de modifier les données sous-jacentes.

Par conséquent, les vues de chaînes sont particulièrement adaptées à la représentation de parties de chaînes plus grandes, par exemple dans un analyseur syntaxique, tandis que les chaînes propriétaires conviennent 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 propriétaire ; 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 propriétaires dans Qt partagent leurs données implicitement, ce qui signifie qu'il est également efficace de passer ou de retourner de grands conteneurs par valeur, bien que légèrement moins efficace que le passage par référence en raison du comptage des références. Si vous voulez utiliser le mécanisme de partage implicite des données des classes Qt, vous devez passer la chaîne en tant que conteneur propriétaire ou en tant que référence à un conteneur. La conversion vers une vue et inversement créera toujours une copie supplémentaire des données.

Enfin, Qt fournit des classes pour les caractères isolés, les listes de chaînes et les comparateurs de chaînes. Ces classes sont disponibles pour la plupart des normes d'encodage supportées 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.

Caractères littéraux

La norme C++ fournit des littéraux de chaîne pour créer des chaînes au moment de la compilation. Il existe des chaînes littérales définies par le langage et des chaînes littérales définies par Qt, appelées chaînes littérales définies par l'utilisateur. Une chaîne littérale définie par le langage C++ est entourée de guillemets doubles et peut avoir un préfixe qui indique 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 au moment de la compilation, ce qui évite de devoir la convertir à partir d'un autre encodage au moment de l'exécution. QStringView peut être construit facilement et efficacement à partir d'un seul, de sorte qu'il peut être passé à des fonctions qui acceptent un argument 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 ajoutent un suffixe après le guillemet fermant. 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 XML les définit donc pour certains de ses propres types de chaînes : u"foo"_s pour QString, "foo"_L1 pour QLatin1StringView et u"foo"_ba pour QByteArray. Elles sont fournies par l'utilisation de StringLiterals Namespace. Une chaîne littérale en C++ simple "foo" sera comprise comme UTF-8 et la conversion en QString et donc en UTF-16 sera coûteuse. Lorsque vous avez des chaînes littérales en ASCII, 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 base

Le tableau suivant donne un aperçu des classes de chaînes 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 et de la bibliothèque standard : Une chaîne de caractères codée en Latin-1 ou UTF-8 peut être std::string ou n'importe quel tableau de 8 bits char. QStringView peut également référencer n'importe quel tableau de caractères de 16 bits, comme std::u16string ou std::wstring sur certaines plates-formes.

Qt XML fournit également des listes spécialisées pour certains de ces types, à savoir QStringList et QByteArrayView, ainsi que des outils de correspondance, QLatin1StringMatcher et QByteArrayMatcher. Les matchers ont également des versions statiques qui sont créées au moment de la compilation, QStaticLatin1StringMatcher et QStaticByteArrayMatcher.

Il convient également de noter que

• QStringLiteral est une macro identique à u"foo"_s et disponible sans StringLiterals Namespace. Il est préférable d'utiliser le littéral de chaîne moderne.
• QLatin1String est un synonyme de QLatin1StringView et existe pour des raisons de compatibilité ascendante. Il ne s'agit pas d'une chaîne propriétaire et pourrait être supprimé dans les prochaines versions.
• QAnyStringView fournit une vue pour une chaîne avec l'un des trois encodages pris en charge. L'encodage est stocké avec la référence aux données. Cette classe est bien adaptée à la création d'interfaces prenant en charge 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 est effectué sur les données sous-jacentes QLatin1StringView, QUtf8StringView ou QStringView dans leur encodage respectif. Utilisez QAnyStringView::visit() pour faire de même 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 codé en UTF-8 et nécessite un traitement spécial, voir la documentation de QLatin1StringView.
• QStringRef est une référence à une partie de QString, disponible dans le module Qt5Compat pour la rétrocompatibilité. Elle doit être remplacée par QStringView.

Classes de haut niveau relatives aux chaînes de caractères

D'autres classes de haut niveau qui fournissent des fonctionnalités supplémentaires fonctionnent principalement avec QString et donc UTF-16. Il s'agit des classes suivantes

• QRegularExpression, QRegularExpressionMatch et QRegularExpressionMatchIterator pour travailler avec la recherche de motifs et les expressions régulières.
• QLocale pour convertir des nombres et des données vers et depuis des chaînes de caractères 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, du script ou du territoire de l'utilisateur.
• QTextBoundaryFinder de découper un texte prêt à être tapé en accord avec les règles Unicode.
• QStringBuilderL'opérateur +, une classe interne qui améliore considérablement les performances des concaténations de chaînes de caractères avec l'opérateur QString, est disponible dans la documentation.

Certaines classes sont des modèles ou ont une API flexible et fonctionnent avec différentes classes de chaînes. Il s'agit des classes suivantes

• QTextStream pour streamer dans QIODevice, QByteArray ou QString
• QStringTokenizer pour diviser les chaînes de caractères

Quelle classe de chaîne utiliser ?

Les conseils généraux pour l'utilisation des classes de chaînes de caractères sont les suivants :

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

Qt fournit 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 y avoir une chaîne ininterrompue de la même classe - la conversion de QString en QStringView et vice-versa donnera deux QStrings qui ne partagent pas leurs données. Par conséquent, les fonctions doivent transmettre leurs données sous la forme de QString (les valeurs ou les références fonctionnent toutes les deux). L'extraction de parties d'une chaîne de caractères n'est pas possible avec le partage implicite des données. Pour utiliser des parties d'une chaîne plus longue, il faut utiliser les vues de chaînes, une forme explicite de partage de données.

Les conversions entre encodages peuvent être réduites en s'en tenant à un certain encodage. Les données reçues, par exemple en UTF-8, sont mieux stockées et traitées en UTF-8 si aucune conversation vers un autre encodage n'est nécessaire. Les comparaisons entre chaînes de caractères du même encodage sont les plus rapides et il en va de même pour la plupart des autres opérations. Si les chaînes d'un certain encodage sont souvent comparées ou converties dans un autre encodage, il peut être avantageux de les convertir et de les stocker une seule fois. Certaines opérations fournissent de nombreuses surcharges (ou une surcharge QAnyStringView ) pour prendre en compte différents types de chaînes et de codages et elles devraient être le deuxième choix pour optimiser les performances, si l'utilisation du même codage n'est pas possible. Les conversions explicites de codage avant l'appel d'une fonction ne doivent être utilisées qu'en dernier recours, lorsqu'aucune autre option n'est disponible. Le Latin-1 est un encodage très simple et les opérations entre le Latin-1 et n'importe quel autre encodage sont presque aussi efficaces que les opérations entre le même encodage.

Le codage 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 le codage. Pour la gestion des erreurs et la journalisation, QLatin1StringView est généralement suffisant. Les chaînes visibles par l'utilisateur dans Qt sont toujours de type QString et, en tant que telles, encodées en UTF-16. Il est donc plus efficace d'utiliser QStrings, QStringViews et QStringLiterals pendant toute la durée de vie d'une chaîne visible par l'utilisateur. La fonction QObject::tr() fournit le codage et le type corrects. QByteArray doit être utilisé si le codage ne joue aucun rôle, par exemple pour stocker des données binaires, ou si le codage est inconnu.

Classe de chaîne pour la création d'une API

Variables membres

Les variables membres doivent être d'un type propriétaire dans presque tous les 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 supérieure à la durée de vie de l'objet.

Arguments de fonction

Les arguments des fonctions doivent être des vues de chaînes de caractères d'un encodage approprié dans la plupart des cas. QAnyStringView peut être utilisé comme paramètre pour prendre en charge plus d'un encodage et QAnyStringView::visit() peut être utilisé en interne pour passer à des fonctions par encodage. Si la fonction est limitée à un seul encodage, QLatin1StringView, QUtf8StringView, QStringView ou QByteArrayView doivent être utilisés.

Si la fonction enregistre l'argument dans une chaîne propriétaire (généralement une fonction setter), il est plus efficace d'utiliser la même chaîne propriétaire comme argument de la fonction afin d'utiliser la fonctionnalité de partage de données implicite de Qt. La chaîne propriétaire peut être transmise sous la forme d'une référence const. La surcharge des fonctions avec plusieurs types de chaînes propriétaires et non propriétaires peut conduire à une ambiguïté de surcharge et doit être évitée. Les types de chaînes propriétaires dans Qt peuvent être automatiquement convertis en leur version non propriétaire ou en QAnyStringView.

Valeurs de retour

Les chaînes temporaires doivent être renvoyées sous la forme d'une chaîne propriétaire, généralement QString. Si la chaîne retournée est connue à la compilation, utilisez u"foo"_s pour construire la structure QString à la compilation. Si des chaînes propriétaires 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 retournées par valeur pour permettre le retour d'une chaîne temporaire dans le futur. L'utilisation par Qt du partage implicite évite l'impact sur les performances de l'allocation et de la copie lors d'un retour par valeur.

Des parties de chaînes existantes peuvent être renvoyées efficacement avec une vue de chaîne de l'encodage approprié. Pour un exemple, voir QRegularExpressionMatch::capturedView() qui renvoie une chaîne de caractères QStringView.

Classe de chaîne 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 vous êtes limité dans votre choix, Qt effectuera diverses conversions : Les chaînes propriétaires sont implicitement converties en chaînes non propriétaires, les chaînes non propriétaires peuvent créer leurs contreparties propriétaires, voir par exemple QStringView::toString(). Les conversions d'encodage sont effectuées implicitement dans de nombreux cas, mais cela devrait être évité si possible. Pour éviter une conversion implicite accidentelle d'UTF-8, vous pouvez activer la macro QT_NO_CAST_FROM_ASCII.

Si vous devez assembler une chaîne de caractères au moment de l'exécution avant de la passer à une fonction, vous aurez besoin d'une chaîne propriétaire et donc de QString. Si l'argument de la fonction est QStringView ou QAnyStringView, il sera implicitement converti.

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

Liste de toutes les classes relatives aux chaînes de caractères