QStringView arrive avec Qt 5.10
La gestion des chaînes de caractères évolue avec C++17 : la classe std::string_view propose la notion de vue sur une chaîne. En d’autres termes, une vue correspond à une référence sur une partie d’une chaîne de caractères. Cela permet de lire des morceaux de chaîne sans devoir allouer de la mémoire et copier des données en grande quantité : la chaîne d’origine est stockée une seule fois. Ces vues ne fonctionnent qu’en lecture, jamais en écriture.
Qt 5.10 proposera sa propre implémentation de ces fonctionnalités dans la classe QStringView. Il n’était pas facilement imaginable de reprendre la version de C++17. Une raison est que Qt requiert C++11, qui ne propose pas cette classe. Une autre, plus importante, est reprise de l’existence même de QString : la gestion d’Unicode, qui permet de représenter n’importe quel caractère, alors que la bibliothèque standard de C++ l’ignore en bonne partie. Une autre raison derrière l’existence de QStringView est d’étendre automatiquement l’interface des fonctions prenant en argument un objet QString pour qu’ils acceptent cette nouvelle classe.
De manière générale, QStringView est une vue en lecture seule sur des objets qui ressemblent à QString (ce qui inclut aussi QStringRef, std::u16string ou encore char16_t).
La plupart des fonctions qui prennent en argument QString n’ont pas besoin de posséder la chaîne de caractères correspondante, une référence faible leur suffit. Certaines fonctions de bas niveau préfèrent donc utiliser un tableau de caractères et une longueur — QStringView propose exactement ce mécanisme, avec la clarté et les garanties de sécurité de QString (impossible de créer une vue de longueur négative, par exemple).
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
bool isValidIdentifier(const QChar *data, int len) {
if (!data || len <= 0)
return false;
if (!data->isLetter())
return false;
--len;
++data;
while (len) {
if (!data->isLetterOrNumber())
return false;
++data;
--len;
}
return true;
} |
Ce code peut être réécrit de manière nettement plus simple et lisible avec QStringView :
Code:
1
2
3
4
5
6
7
8
9
10
11
| bool isValidIdentifier(QStringView id) noexcept {
if (id.isEmpty())
return false;
if (!id.front().isLetter())
return false;
for (QChar ch : id.mid(1)) {
if (!ch.isLetterOrNumber())
return false;
}
return true;
} |
L’attrait pour QStringView vient aussi du nombre de types que les constructeurs de la classe acceptent. Ainsi, ils permettent de s’abstraire complètement du conteneur des données (QString, QStringRef, std::u16string ou encore char16_t sont tous gérés), mais aussi du type des caractères (QChar, ushort, char16_t ou encore wchar_t).
Code:
1
2
3
4
5
6
7
8
| bool isValidIdentifier(QStringView id);
isValidIdentifier(u"QString"); // OK
isValidIdentifier(L"QString"); // OK (Windows uniquement)
isValidIdentifier(QStringLiteral("QString")); // OK
QString fun = "QString::left()";
isValidIdentifier(fun.leftRef(7)); // OK
isValidIdentifier(u"QString"s); // OK
isValidIdentifier(L"QString"s); // OK (Windows uniquement) |
Cependant, cette flexibilité n’est pas encore aussi grande que QString : impossible de transformer directement un QChar, une QLatin1String ou un QStringBuilder.
D’ici à la version finale de Qt 5.10, les développeurs espèrent avoir répliqué toute l’interface constante de QString, à quelques exceptions près. Par exemple, il n’y aura pas de méthode split : cela nécessiterait de renvoyer un conteneur de sous-chaînes dont la taille n’est pas connue à la compilation, alors que l’objectif de QStringView est justement d’éviter toute allocation de mémoire. Il devrait y avoir une classe QStringTokenizer pour gérer ces cas.
Source : QStringView Diaries: The Eagle Has Landed.
