Discussion :

[Ah_Kin]

Bonjour, c'est simple, quelqu'un peut me dire pourquoi y'a pas moyen de supprimer le dernier élément d'un QList avec removeAt ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
QList<QString>* test = new QList<QString>;
test->insert(0, "test1");
test->insert(1, "test2");
test->insert(2, "test3");
qDebug() << test->at(2);
test->removeAt(2);
qDebug() << test->at(2);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
"test3"
"test3"

[mintho carmo]

Ton élément est supprimé, affiche la taille de la liste pour confirmation.
Accéder à un élément invalide provoque un comportement indéterminé, ie le programme fait n'importe quoi. En particulier, il peut aller chercher dans la mémoire à l'ancien emplacement de l'élément et faire comme s'il était encore présent. Et si la mémoire n'a pas été modifiée, tu auras l'impression que l'élément n'est pas supprimé de la liste.
Donc toujours tester l'accès à un élément avant de le faire.
HS : pas de raison de créer un pointeur de QList

[chrtophe]

Il fat aussi savoir que Qt est conçu pour optimiser les appels mémoire. Ton élément est supprimé mais son espace mémoire est non libéré.

[Ah_Kin]

Ton élément est supprimé, affiche la taille de la liste pour confirmation.
Accéder à un élément invalide provoque un comportement indéterminé, ie le programme fait n'importe quoi. En particulier, il peut aller chercher dans la mémoire à l'ancien emplacement de l'élément et faire comme s'il était encore présent. Et si la mémoire n'a pas été modifiée, tu auras l'impression que l'élément n'est pas supprimé de la liste.
Donc toujours tester l'accès à un élément avant de le faire.
HS : pas de raison de créer un pointeur de QList

Si j'utilise un pointeur c'est qu'en fait j'en ai besoin, dans le code d'origine il s'agit d'une variable membre. Le programme plante quand par exemple on appelle test->at(12). Je ne comprends pas pourquoi il ne plante pas quand on appelle test->at(2), si la méthode était pondue correctement, ça devrait planter. Je teste l'affichage de size dès que possible.

[mintho carmo]

Si j'utilise un pointeur c'est qu'en fait j'en ai besoin, dans le code d'origine il s'agit d'une variable membre.

Quel rapport ?
Non, il n'y a a priori aucune raison de créer un pointeur de QList

si la méthode était pondue correctement, ça devrait plante

C'est une question de choix de conception. En C++, on considère que c'est au développeur de faire les choses correctement, pas à la lib de vérifier les erreurs des devs (parce que cela à un coût sur les performances).

Donc ajoute un assert à chaque fois que tu utilises un pointeur ou accède à un tableau

[Ah_Kin]

Quel rapport ?
Non, il n'y a a priori aucune raison de créer un pointeur de QList


C'est une question de choix de conception. En C++, on considère que c'est au développeur de faire les choses correctement, pas à la lib de vérifier les erreurs des devs (parce que cela à un coût sur les performances).

Donc ajoute un assert à chaque fois que tu utilises un pointeur ou accède à un tableau

Typiquement, il vaut mieux utiliser des pointeurs pour les variables membres pour une classe histoire de pas avoir d'objet pesant.
Je vérifierai dès que possible le size, mais s'il s'avère que le size ne change pas quand on enlève un élément, il sera clair que la définition de removeAt est erronée quelle qu'en soit la raison.

[mintho carmo]

Typiquement, il vaut mieux utiliser des pointeurs pour les variables membres pour une classe histoire de pas avoir d'objet pesant.

Combien "pèse" un QList ? Sais tu comment est implémenté une liste ? Ce qu'est le COW ou implicit sharing ?

Je te demandais pas pour quelle raison tu avais utilisé un pointeur. Je te disais juste qu'il ne fallait pas. Si tu penses avoir de bonnes raisons pour croire cela, sois tu es un expert en C++ et Qt et tu n'as pas besoin de vérifier ce que tu penses, soit ce n'est pas le cas et tu devrais peut être vérifier ce que tu crois quand on te dis que tu fais une erreur.

[Ah_Kin]

Combien "pèse" un QList ? Sais tu comment est implémenté une liste ? Ce qu'est le COW ou implicit sharing ?

Je te demandais pas pour quelle raison tu avais utilisé un pointeur. Je te disais juste qu'il ne fallait pas. Si tu penses avoir de bonnes raisons pour croire cela, sois tu es un expert en C++ et Qt et tu n'as pas besoin de vérifier ce que tu penses, soit ce n'est pas le cas et tu devrais peut être vérifier ce que tu crois quand on te dis que tu fais une erreur.

Ok j'ai dû oublier le principe d'une liste : un élément, le pointeur vers un autre élément. D'après ce qui se passe, removeAt ne fait donc que remplacer éventuellement un pointeur par un autre déjà présent dans la liste. ce qu'il faut donc faire, c'est aussi désallouer manuellement. Il faut donc faire une QList de pointeurs au lieu effectivement de faire un pointeur de QList qui en fait est elle même un pointeur. Le dernier élément ne peut pas prendre la valeur null car la cellule non désallouée serait perdue. Mais sachant que de toute façon la cellule supprimée par e.g. removeAt(n), n non dernier, est non désallouée, comment la retrouve-ton? Le problème est le même, aussi ils auraient quand même pu lui affecter null je trouve, à moins ça demande trop d'effort effectivement de créer un null, vu que donc removeAt ne crée rien. Bon, j'imagine qu'on va s'en tenir à cette explication.

EDIT : pas affecter null, mais libérer la mémoire. C'est pas pris en charge, entendu.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
QList<QString *>QList<QString *> test;
QString * item = new QString("test1");
test.insert(0, item);
item = new QString("test2");
test.insert(1, item);
item = new QString("test3");
test.insert(2, item);
 
qDebug() << *(test.at(2));
qDebug() << test.size();
qDebug() << "pass 1";
delete(test.at(2));
qDebug() << "pass 2";
test.removeAt(2);
qDebug() << "pass 3";
qDebug() << *(test.at(2));
qDebug() << "pass 4";
qDebug() << test.size();

=>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
"test3" 
3 
pass 1 
pass 2 
pass 3

[mintho carmo]

Euh... oublie un peu les pointeurs. Tu les utilises n'importe ou, quand ce n'est pas utile. Surtout que cela produit des fuites mémoires.
Tu n'as aucune raison de créer des pointers de QList ou QString.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
QList<QString> test; // idem QStringList
test.insert(0, "test 1"); // ou append
test.insert(1, "test 2");
test.insert(2, "test 3");
 
Q_ASSERT(test.size() > 2);
qDebug() << test.at(2); // on accède a l’élément 2 donc on test avant
 
qDebug() << test.size();
qDebug() << "pass 1";
qDebug() << "pass 2";
 
Q_ASSERT(test.size() > 2);
test.removeAt(2); // on accède a l’élément 2 donc on test avant
 
qDebug() << "pass 3";
 
Q_ASSERT(test.size() > 2);
qDebug() << test.at(2); // on accède a l’élément 2 donc on test avant
qDebug() << "pass 4";
qDebug() << test.size();

Pour le moment, tu fais n'importe quoi, donc ne t’étonne pas si tu obtiens n'importe quoi.

EDIT : correction assert, cf message suivant

[Ah_Kin]

En parlant de faire n'importe quoi, je suppose que tu voulais dire q_assert size > 2 ?

Merci pour l'explication.

[koala01]

Salut,

Typiquement, il vaut mieux utiliser des pointeurs pour les variables membres pour une classe histoire de pas avoir d'objet pesant.

Heu... Juste une question...

Que se passe-t-il, selon toi, lorsque tu fait appel à new pour initialiser ton pointeur à une valeur correcte

La réponse est simple : l'objet du type demandé est créé... Mais pas dans l'air du temps : en mémoire -->cout = poids de l'objet lui-même + poids du pointeur (car, oui, un pointeur a une emprunte mémoire, même si elle est "limitée" au type entier non signé susceptible de représenter "n'importe quelle adresse valide" )

Alors, maintenant, tu pensais peut être quelque chose comme "... histoire de pas avoir d'objet pesant sur la pile".

Mais là encore, tu as tout faux car, les collections dynamique ont toujours une emprunte mémoire excessivement faible sur la pile, ne serait-ce que parce que tous les éléments sont stocké... sur le tas.

De plus -- et c'est particulièrement vrai avec Qt -- lorsqu'un objet est créé sur le tas (typiquement avec appel à new, comme tu le feras pour la plupart des classes dérivées de QObject et donc, sans doute pour n'importe quelle classe qui utilisera une QList), tous ses membres sont forcément créés dans le tas, et non dans la pile.

Finalement, le seul cas où ta QList (enfin, ou une partie de ta QList) se trouvera dans la pile, c'est si tu crées une instance de QList comme variable locale d'une fonction. Et ca, ca n'aura (normalement) que très peu d'incidence, étant donné que cette variable locale sera détruite dés que l'on quittera la portée de la fonction

Au final, je ne sais pas où tu as été pêcher ce genre de raisonnement, mais je suis au regret de te dire que cette justification n'a absolument rien de correct

[Ah_Kin]

La meilleure chose à faire serait de faire une fonction avec passage par référence en effet. Là, depuis le début, il s'agissait juste d'un test, vous l'avez constaté, vous avez fait ma fête, c'était un peu n'importe quoi, et c'était fait exprès. C'est simple, je voulais savoir comment faire pour que le programme plante.

[Ah_Kin]

Euh... oublie un peu les pointeurs. Tu les utilises n'importe ou, quand ce n'est pas utile. Surtout que cela produit des fuites mémoires.
Tu n'as aucune raison de créer des pointers de QList ou QString.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
QList<QString> test; // idem QStringList
test.insert(0, "test 1"); // ou append
test.insert(1, "test 2");
test.insert(2, "test 3");
 
Q_ASSERT(test.size() > 2);
qDebug() << test.at(2); // on accède a l’élément 2 donc on test avant
 
qDebug() << test.size();
qDebug() << "pass 1";
qDebug() << "pass 2";
 
Q_ASSERT(test.size() > 2);
test.removeAt(2); // on accède a l’élément 2 donc on test avant
 
qDebug() << "pass 3";
 
Q_ASSERT(test.size() > 2);
qDebug() << test.at(2); // on accède a l’élément 2 donc on test avant
qDebug() << "pass 4";
qDebug() << test.size();

Pour le moment, tu fais n'importe quoi, donc ne t’étonne pas si tu obtiens n'importe quoi.

EDIT : correction assert, cf message suivant

Avec ou sans pointeur, on a quand même une erreur. Aussi il fau(drai)t désallouer la mémoire, ou en bref, créer une classe héritant de QList<QString> avec un destructeur, voire réécrire le destructeur en utilisant les euh implicit sharing. QList ne gère pas la mémoire prise par les éléments.

Explication succincte et vraie donnée par chrtophe.
Merci à mes amis mintho carmo, et koala01 pour les corollaires (veiller à désallouer la mémoire à chaque fois qu'on la réserve délibérément).

EDIT : désallouer, ou plutôt libérer. Utiliser delete, quoi. Désolé je suis très concis pour ce sujet, c'était vraiment une question vite fait.

[koala01]

Avec ou sans pointeur, on a quand même une erreur. Aussi il fau(drai)t désallouer la mémoire, ou en bref, créer une classe héritant de QList<QString> avec un destructeur, voire réécrire le destructeur en utilisant les euh implicit sharing. QList ne gère pas la mémoire prise par les éléments.

Ah, non... Tout ce qui n'est pas créé au travers de new sera automatiquement détruit une fois correctement retiré de la liste... Si tu arrives encore à obtenir un résultat "cohérent" par rapport à ce qui était dans la liste à un moment donné, c'est juste par "un coup de chance" qui veut que la mémoire n'aura pas encore été réutilisée (et, peut-être, mais à vérifier, parce que la liste aura décidé de garder cette mémoire pour "un usage ultérieur", histoire de ne pas passer son temps à demander de la mémoire à l'OS pour la lui rendre "tout de suite après"

Après, il est "normal" que QList ne choisisse pas d'appeler delete sur les (pointeurs vers des) objets qu'elle peut éventuellement contenir... A partir du moment où tu as décidé de gérer toi-même la durée de vie des objets en invoquant -- peut être de manière indirecte (c'est, par exemple, ce que font std::make_shared et std::make_unique en C++14 ) -- new, il est logique qu'elle ne prenne pas la décision de libérer la mémoire allouée si tu ne lui dit pas explicitement qu'elle doit s'en charger (en utilisant les pointeurs intelligents, que ce soit ceux de C++11 et suivant ou ceux fournis par Qt )

Il faut d'ailleurs noter que QList a un comportement bâtard dans le sens où elle fournit un opérateur [] (ce qui est théoriquement illogique pour une liste ). A partir de là, et bien que je n'ai jamais été voir dans les entrailles de cette classe, il y a deux solutions possibles : soit elle est implémentée sous la forme d'un tableau -- tres bon pour les accès aléatoires, plus embêtant du point de vue de l'utilisation de la mémoire (mais qui permettrait aussi de comprendre comment on peut continuer d'accéder à un élément qui n'est plus sensé exister )-- soit elle est effectivement implémentée sous la forme d'une liste (simplement ou doublement chainée), et l'opérateur [] n'accède pas aux éléments en temps constant

[mintho carmo]

Avec ou sans pointeur, on a quand même une erreur.

Quelle erreur ?

Je ne sais pas très bien ce que tu essaies de montrer, mais les erreurs dont tu parles depuis le début de ce post sont des erreurs de programmation (ie de ta part, dues a une mauvaise utilisation de QList).

Tu n'as pas a hériter de QList pour réécrire le destructeur. D'abord, cela ne servira a rien, puisque tu n'auras pas accès aux membres privés de QList. Ensuite, les éléments sont correctement libérés - ie réutilisable par le QList pour d'autres éléments - sauf si tu utilises des pointeurs.
Et bien sur que QList gère la mémoire de ses éléments, c'est son boulot (cf RAII)

[mintho carmo]

Il faut d'ailleurs noter que QList a un comportement bâtard dans le sens où elle fournit un opérateur [] (ce qui est théoriquement illogique pour une liste ). A partir de là, et bien que je n'ai jamais été voir dans les entrailles de cette classe, il y a deux solutions possibles : soit elle est implémentée sous la forme d'un tableau -- tres bon pour les accès aléatoires, plus embêtant du point de vue de l'utilisation de la mémoire (mais qui permettrait aussi de comprendre comment on peut continuer d'accéder à un élément qui n'est plus sensé exister )-- soit elle est effectivement implémentée sous la forme d'une liste (simplement ou doublement chainée), et l'opérateur [] n'accède pas aux éléments en temps constant

En fait, QList n'est pas une liste (pas une liste chaînée). Si T est de petite taille, ca sera un tableau de T, si T est plus gros qu'un pointeur, ca sera un tableau de pointeurs. Il faut utiliser QLinkedList pour avoir une liste chaînée avec Qt

[Ah_Kin]

Mon ami, il s'agissait simplement d'un test, désolé de ne pas avoir fait un logiciel embarqué pour une réutilisation sérieuse.

[mintho carmo]

Mon ami, il s'agissait simplement d'un test, désolé de ne pas avoir fait un logiciel embarqué pour une réutilisation sérieuse.

J'ai un peu de mal a comprendre ou tu veux en venir. J'ai l'impression que tu essaies de faire de l'esprit (c'est ton problème), mais au final tu sembles conclure des choses fausses de tes tests. Ou alors je n'ai pas compris ce que tu déduis de tes tests.

[Ah_Kin]

Je tenais à savoir le pourquoi on avait toujours accès à un élément removAté, notamment le dernier de la liste. Il nous a été expliqué qu'en fait removeAt ne nettoie pas derrière, et que ce qui confirme que l'élément n'est plus là est size().

Vous m'avez averti que l'utilisation de pointeur n'est pas pertinente et peu sûre niveau mémoire, que les pointeurs eux même utilisent aussi de la mémoire quand on les instancie, dans le haystack pile, ou le tas, whatever, ce qui fait qu'en fait en voulant optimiser, je fais le contraire, mais ce que j'ai appris dans tout ça, je le savais déjà, sauf peut être en ce qui concerne le implicit sharing, ou le cow. Je suis très reconnaissant que tu m'aies apporté ces informations et que tu m'aies rafraichi la mémoire sur certains points. Ces lignes ne sont qu'un test par rapport à ce que je suis en train de faire, et pour tout dire, tout fonctionne bien, même avec ces pointeurs, sachant qu'en plus bien des méthodes requièrent des pointeurs et non des variables d'un type bien précis. J'ai repris mon code d'une certaine façon et il fonctionne, à savoir qu'il s'agit d'un vieux code qui date de quelques années et qui a pu gérer tant bien que mal les problèmes de synchronisation de méthodes asynchrones. Une fois que tout sera fini, si tu veux je t'envoie le lien vers le logiciel qui s'y rapporte.

la sécurité requise en utilisant q_assert, t'inquiète j'ai compris tout ça.