Je prêche certainement des convaincus ici, mais en allant jeter un oeil à ton commit sur le mémory leak (cas 3), je me rends compte que c'est un code signalé par le compilateur par un warning.
Alors oui mais non :(
Ni GCC 10, ni Clang 11, ni clang-analyzer, ni clazy n'ont signalé cette fuite.
KWPage page = pageManager->page(request->pageNumber()+1);
pix = new QPixmap(request->width(), request->height());
QPainter painter(pix);
QSize rSize(request->width(), request->height());
pix = new QPixmap();
L'objet alloué inutilement ligne 3 est donné à un objet sur la pile ligne 4. Ce second objet n'est pas utilisé et est détruit ultérieurement.
Mais le compilateur n'a aucune information sur les effets de bord possibles de la ligne 4. Ce serait une mauvaise conception, mais l'objet créé sur la pile pourrait prendre «possession» du pointeur et le détruire à sa libération. Ce pourrait être l'équivalent d'un std::unique_ptr...
Mais je suis parfaitement d'accord, moins de warning est souvent synonyme de moins de bugs. J'ai par exemple trouvé dans Calligra un code qui fonctionnait en 32 bits mais pas en 64 bits grâce à un warning...
[^] # Re: Memory leak et warnings
Posté par Pinaraf . En réponse au journal 723, +5736, -5696... un mois de travail de résurrection d'un projet libre.... Évalué à 9.
Alors oui mais non :(
Ni GCC 10, ni Clang 11, ni clang-analyzer, ni clazy n'ont signalé cette fuite.
L'objet alloué inutilement ligne 3 est donné à un objet sur la pile ligne 4. Ce second objet n'est pas utilisé et est détruit ultérieurement.
Mais le compilateur n'a aucune information sur les effets de bord possibles de la ligne 4. Ce serait une mauvaise conception, mais l'objet créé sur la pile pourrait prendre «possession» du pointeur et le détruire à sa libération. Ce pourrait être l'équivalent d'un
std::unique_ptr...Mais je suis parfaitement d'accord, moins de warning est souvent synonyme de moins de bugs. J'ai par exemple trouvé dans Calligra un code qui fonctionnait en 32 bits mais pas en 64 bits grâce à un warning...