Discussion :

[laerne]

Bonjour, aujourd'hui j'ai été à une conférence de Bjarne Stroustrup (un ponte quoi) dans sa ville natale. Il nous a raconté comment sa vision pour écrire du beau c++, et donc des raisons de 2-3 nouveautés utile de c++2011 dans ce sens-là, et je voulais partager avec vous l'expérience.

Il nous d'abord parlé de qsort() et pourquoi c'était une mauvaise fonction car son interface requiert de nombreux paramètres qui rende un appel peu clair à lire, et parce que son implémentation utilisais beaucoup de trucs « trop » générique qui plombe la performence de l'algorithme. Par ailleurs il n'apprécaient pas le type-safety réduit de qsort().

Ensuite un petit mot sur la sur-utilisation des types basiques générique qui rendent le code peu clair quand on travaille avec des unités. Ainsi il faudrait définir un type de donnés « speed » plutôt que d'enregistrer tout dans des double, car on ne sait à quel unité correspond les double. Cet exemple était motivé par le crash de je-ne-sais-plus-lequel satellite qui s'était planté sous mars à cause d'une erreur d'intérprètation d'unité.

Puis un peu d'algorithmie ou il est sortit très étonnement que le std::vector était le conteneur le plus performant pour insérer et retirer plein de petit nombre (même meilleur qu'un arbre) ! Bjarne explique que c'est parce que les données sont compacte et donc qu'il y a moins de « cache misses » et moins de pointeur à déréférencer, ce qui augmente le nombre d'instruction. Bjarne recommande d'utiliser que trois conteneurs : std::vector, std::map (ou unordered_map) ou une single-linked list si on a besion d'un conteneur souvent vide.

Par après, une petite discussion sur la gestion de la ressource. Le couple allocation de la ressource/libération de la recoussource serait à proscrire car il mène facilement à un oubli de libération de la ressource si une erreur survient pendant la gestion de la ressource. Les try-catch ne pas beaucoup mieux car il rendrait le code peut lisible, donc peu maintenable. Bjarne propose évidemment d'utiliser des «*poignées*», ces objets dont le constructeur de charge d'allouer la ressource et le destructeur se charge de la libérer. Comme le destructeur est appelé à la fin de toute fonction, plus de problème.

Bjarne parle aussi des retours de fonction. Par exemple, comment renvoier la somme de deux matrices.
Renvoier un pointeur est dangereux, car on a du mal à savoir qui doit libérer la matrice créée, et on ne peut écrire la somme de 3 matrices simplement. Pour cette dernière raison, renvoyer une référence est aussi mauvaise. Passer la matrice ou enregistrer le résultat comme troisième argument est plus sur, mais rend l'appel de fonction très peu lisible, et renvoyer la matrice directement implique de copier beaucoup de données. Bjarne propose d'utiliser des constructeurs de déplacement (utilisant des références RHS) pour déplacer les données (changer les pointeur) plutôt que de les copier.

Voilà, j'espère que ça vous intéresse, même s'il y a pas mal de connu. Perso ce qui m'a le plus surpris, c'est le coup du std::vector.

[Flob90]

En effet rien de nouveau du côté des problèmes du C++ avant le C++11 (ce sont tous des constats qui ont 10 ans, ou presque), mais ca résume bien les solutions misent en oeuvre par le C++11 pour les résoudre.

[Klaim]

Il a fait la meme presentation (avec un graphique absent sur sa presentation...) lors de l'ouverture de Going Native : http://channel9.msdn.com/Events/Goin...up-Cpp11-Style

[laerne]

Ah ben merci, klaim*! En fait la description est la même… Mais il nous avait assuré que c'était une nouvelle conférence.

En tout cas ça me permettra de revisionner la conf merci encore.

[Kaamui]

Bonjour, aujourd'hui j'ai été à une conférence de Bjarne Stroustrup (un ponte quoi) dans sa ville natale. Il nous a raconté comment sa vision pour écrire du beau c++, et donc des raisons de 2-3 nouveautés utile de c++2011 dans ce sens-là, et je voulais partager avec vous l'expérience.

Il nous d'abord parlé de qsort() et pourquoi c'était une mauvaise fonction car son interface requiert de nombreux paramètres qui rende un appel peu clair à lire, et parce que son implémentation utilisais beaucoup de trucs « trop » générique qui plombe la performence de l'algorithme. Par ailleurs il n'apprécaient pas le type-safety réduit de qsort().

Ensuite un petit mot sur la sur-utilisation des types basiques générique qui rendent le code peu clair quand on travaille avec des unités. Ainsi il faudrait définir un type de donnés « speed » plutôt que d'enregistrer tout dans des double, car on ne sait à quel unité correspond les double. Cet exemple était motivé par le crash de je-ne-sais-plus-lequel satellite qui s'était planté sous mars à cause d'une erreur d'intérprètation d'unité.

Puis un peu d'algorithmie ou il est sortit très étonnement que le std::vector était le conteneur le plus performant pour insérer et retirer plein de petit nombre (même meilleur qu'un arbre) ! Bjarne explique que c'est parce que les données sont compacte et donc qu'il y a moins de « cache misses » et moins de pointeur à déréférencer, ce qui augmente le nombre d'instruction. Bjarne recommande d'utiliser que trois conteneurs : std::vector, std::map (ou unordered_map) ou une single-linked list si on a besion d'un conteneur souvent vide.

Par après, une petite discussion sur la gestion de la ressource. Le couple allocation de la ressource/libération de la recoussource serait à proscrire car il mène facilement à un oubli de libération de la ressource si une erreur survient pendant la gestion de la ressource. Les try-catch ne pas beaucoup mieux car il rendrait le code peut lisible, donc peu maintenable. Bjarne propose évidemment d'utiliser des «*poignées*», ces objets dont le constructeur de charge d'allouer la ressource et le destructeur se charge de la libérer. Comme le destructeur est appelé à la fin de toute fonction, plus de problème.

Bjarne parle aussi des retours de fonction. Par exemple, comment renvoier la somme de deux matrices.
Renvoier un pointeur est dangereux, car on a du mal à savoir qui doit libérer la matrice créée, et on ne peut écrire la somme de 3 matrices simplement. Pour cette dernière raison, renvoyer une référence est aussi mauvaise. Passer la matrice ou enregistrer le résultat comme troisième argument est plus sur, mais rend l'appel de fonction très peu lisible, et renvoyer la matrice directement implique de copier beaucoup de données. Bjarne propose d'utiliser des constructeurs de déplacement (utilisant des références RHS) pour déplacer les données (changer les pointeur) plutôt que de les copier.

Voilà, j'espère que ça vous intéresse, même s'il y a pas mal de connu. Perso ce qui m'a le plus surpris, c'est le coup du std::vector.

premièrement superbe initiative de ta part : +1 (même si ça existait déjà apparemment, le rappeler est toujours bon, personnellement j'aprécie beaucoup ton post).

Ensuite : le satellite était en fait une sonde : Mars Climate Orbiter

Enfin : merci pour la vidéo oui (on a quand même de la chance d'avoir l'inventeur encore bien vivant à notre portée^^ (vous imaginez la frustration pour les passionné de physique de pas avoir rencontré ou visionné Enstein ?) )