Distinguished Lecture: Bjarne Stroustrup
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.
