Discussion :

[LittleWhite]

Bonjour à tous,

Dans cet article, traduit par Eric GERARD, vous allez apprendre comment éviter les erreurs de mémoire grâce au C++11. De plus, vous verrez l'utilisation de valgrind afin de détecter ces erreurs liées à la mémoire.

Bonne lecture

[mintho carmo]

L'article n'est pas inintéressant, mais au final :
- beaucoup d'exemples donnés sont des problèmes qui ne devrait plus avoir lieu déjà en C++03 (utilisation de new[] au lieu de vector, utilisation de pointeurs au lieu de références, variables non initialisée)
- ce sont des exemples de problème d'utilisation des structures brutes en générale, qui sont solutionné par le RAII
- seul l'exemple sur la tableau de taille statique à une solution spécifique en C++11 (std::array)
- l'article parle plus de l'utilisation de valgrind et les principaux types de problèmes qu'il permet de diagnostiquer que des solutions apportées par le C++11 (il y a juste quelques lignes à la fin)
Quand je vois la partie VIII, je me demande si l'auteur connait le RAII...
Pour la partie IX, c'est tellement survolé que l'on peut pas dire grand chose. Sauf peut être que j'ai entendu un certain Luc dire que vector::at() est de la programmation défensive, donc pas forcement une bonne pratique (cf son blog - qu'en est-ce que le troisième article sera publié ? )

[LittleWhite]

Je ne le voyais pas de la sorte, mais plus :

• le C++ permet d'utiliser les pointeurs (allocation dynamique). Cela peux aussi vous amener à faire des fuites de mémoire ;
• voici ce que sont les fuites de mémoire ;
• voici comment ont les détecte ;
• voici des (quelques ?) solutions.

D'ailleurs, le deuxième point, dans VIII, pour moi, c'est faire du RAII :

Lorsque vous utilisez un pointeur local dans une fonction membre (qui n'est pas un attribut de la classe courante), il est hautement probable qu'une variable locale soit suffisante ;

Mais il est possible que j'extrapole un peu

Pour la partie XI, bah après les détails sont à trouver dans un cours C++ détaillé sur C++11, ou encore, vous les connaissez déjà
Cet article est plus pour les débutants, qui ne connaissent pas spécialement les fuites de mémoire.

[bountykiler]

L'article n'est pas inintéressant, mais au final :
- beaucoup d'exemples donnés sont des problèmes qui ne devrait plus avoir lieu déjà en C++03 (utilisation de new[] au lieu de vector, utilisation de pointeurs au lieu de références, variables non initialisée)
- ce sont des exemples de problème d'utilisation des structures brutes en générale, qui sont solutionné par le RAII
- seul l'exemple sur la tableau de taille statique à une solution spécifique en C++11 (std::array)
- l'article parle plus de l'utilisation de valgrind et les principaux types de problèmes qu'il permet de diagnostiquer que des solutions apportées par le C++11 (il y a juste quelques lignes à la fin)
Quand je vois la partie VIII, je me demande si l'auteur connait le RAII...
Pour la partie IX, c'est tellement survolé que l'on peut pas dire grand chose. Sauf peut être que j'ai entendu un certain Luc dire que vector::at() est de la programmation défensive, donc pas forcement une bonne pratique (cf son blog - qu'en est-ce que le troisième article sera publié ? )

Tout à fait d'accord avec toi. Quand j'ai vu que l'auteur prétend combattre les erreurs mémoie en c++11 en parlant de valgrind, et en prenant comme exemple du code avec des pointeurs nu, des new et des delete, je n'ai eu qu'une envie : lui mettre des baffes! Après, c'est vrai qu'il en parle à la fin, mais c'est fait de façon tellement annectodique. Le minimun aurait été de reprendre les exemples du dessus et de montrer comment utiliser des smart pointeurs pour chacun.
Ce qui me dérange le plus, c'est que c'est typiquement le genre d'article qui va faire croire aux novices que la gestion de la mémoire est quelque chose d'ultra compliqué et risque au final de les éloigner du C++, alors qu'en réalité il s'agit d'un problème qui est loin d'etre insurmontable.

[mintho carmo]

Pour les débutants, je ne suis pas sur. A un débutant, on lui montre les bonnes pratiques (il n'est pas nécessaire de s'attarder sur les mauvaises, il les apprendra très bien tout seul).
Pour ceux qui écrivent ce genre de code, mais ne savent pas que cela risque de provoquer des fuites mémoire, je pense comme bountykiler qu'il aurait fallut présenter aussi le code correct en C++ "moderne" (pas forcement C++11, puisque beaucoup de problèmes signalés sont déjà réglés par le C++03 et surtout le RAII)

Je ne critique pas le contenu de l'article en lui même. Apprendre à utiliser valgrind est toujours intéressant et il est utile pour les apprenants qui doivent faire la transition C++ "moderne" vers C++ old-school de savoir comment détecter les problèmes liés à ce genre de code.

Mais j'ai du mal avec le titre, en particulier "C++11" et il manque des choses (les bonnes pratiques)

[gl]

Je rejoins mintho carmo : ça reste intéressant comme article de présentation de valgrind mais ce n'est pas un article sur "combattre les fuites et erreurs mémoires en C++".

Au passage sur le chapitre IX "Facilités de C++11", outre ce qui a déjà été dit, il y a à la fois du C++03 (voire 98), C++11 et C++14 contrairement à ce que le titre suggère.

[Luc Hermitte]

valgrind, c'est mignon quand on n'a que ça (pour les objectifs de l'article) -- à condition de l'avoir aussi. Depuis, j'ai découvert les modes sanatize de clang et ... ça change la vie. Mieux que de savoir que l'on accède à une zone de mémoire qui ne nous appartient pas, il va aussi nous dire où la zone a été allouée ou aurait du être allouée (quand on est quelques octets après un buffer). Là, on est vraiment un niveau au dessus.

Dernièrement, j'ai aussi eu à me battre avec des "Conditional jump or move depends on uninitialised value(s)". En termes d'origine de la valeur non initialisée je n'avais pas trouvé valgrind très bon sur des "int x = f(); if (x) ..." pour indiquer quel chemin dans f aura provoqué ces valeurs non initialisées. Je n'ai pas eu le temps de creuser le mode de sanatization (expérimental) équivalent malheureusement. Où alors c'était fait de façon statique, car il m'avait détecté plein d'idioties du genre "S::S(S const& rhs_) : m_i(m_i) {}" ou "S & S::operator=(S const& rhs_) { m_i = m_i; }" à la compilation.

Pour la Programmation Défensive, oui cela en est effectivement. Et effectivement, je n'en pense pas du bien. Pour le 3e article, il est quasi prêt. J'ai juste un paragraphe à fignoler (et j'hésite à intégrer un mot sur les tous derniers papiers des derniers meetings au second article -- car sinon, je ne vais jamais m'en sortir).

J'y pense, la classe Database n'est pas robuste à la duplication non plus.
Après en effet, l'article aurait plus dû s'appeler "traquer les fuites de mémoire" que "combattre". Car on commence par combattre avec un egrep "new|alloc|fopen" (C++14); et un egrep "delete|free|close" qui ne doit renvoyer aucune occurrence hors destructeur (C++98). Les erreurs d'accès (mauvais index), c'est l'étape d'après. Sur le sujet on a aussi les assertions, et peut être un jour une analyse statique des contrats -- cela dépendra du résultat des discussions sur le sujet lors des divers meetings de préparation du C++17.