Recherche…


Remarques

Les itérateurs de style STL sur Qt Container peuvent avoir des effets secondaires négatifs dus au partage implicite. Il est conseillé d'éviter de copier un conteneur Qt alors que des itérateurs sont actifs dessus.

QVector<int> a,b; //2 vectors
a.resize(1000); 
b = a; // b and a now point to the same memory internally

auto iter = a.begin(); //iter also points to the same memory a and b do
a[4] = 1; //a creates a new copy and points to different memory.
//Warning 1: b and iter point sill to the same even if iter was "a.begin()"

b.clear(); //delete b-memory
//Warning 2: iter only holds a pointer to the memory but does not increase ref-count. 
//           so now the memory iter points to is invalid. UB!

Concept de base

Plusieurs objets et conteneurs Qt utilisent un concept appelé partage implicite , qui peut également être appelé copie sur écriture .

Le partage implicite signifie que les classes qui utilisent ce concept partagent les mêmes données lors de l'initialisation.

L'une de ces classes pour utiliser le concept est QString.

QString s1("Hello World");

Une initialisation de QString

Ceci est un modèle simplifié d'un QString. En interne, il possède un bloc de mémoire, avec les données de chaîne réelles et un compteur de référence.

QString s2 = s1;

copier QString

Si nous copions maintenant cette QString deux objets pointeront en interne sur le même contenu, évitant ainsi des opérations de copie inutiles. Notez comment le compte de référence a également été augmenté. Donc, si la première chaîne est supprimée, les données partagées savent toujours qu'elle est référencée par une autre QString .

s2 += " and all the other Worlds!"

Copier sur écrire

Maintenant, lorsque la QString est réellement modifiée, l'objet "se détache" du bloc mémoire, copiant son contenu et en modifiant le contenu.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow