GoingNative 2013 - Bjarne Stroustrup - L'Essence du C++ : avec des exemples en C++84, C++98, C++11, et C++14
Bjarne Stroustrup - L'Essence du C++ : avec des exemples en C++84, C++98, C++11, et C++14
GoingNative 2013
La conférence de B. Stroustrup lors des GoingNative 2013 est maintenant disponible en rediffusion :
Voici un résumé qui ne contient volontairement pas tous les éléments de la conférence, mais seulement ceux qui m'ont paru importants et/ou intéressants.
Ce qu'il voulait/veut pour le C++ :
- Sécurité des types : on encapsule les opérations dangereuses mais nécessaires ;
- Sécurité des ressources* ;
- Performance : c'est important pour la grande majorité des systèmes ;
- Prévisibilité : un code prévisible est un code sur lequel on peut compter ;
- Enseignabilité : la complexité du code devrait être proportionnelle à la difficulté de la tâche, "garder les choses simples simples";
- Lisibilité : les hommes autant que les machines doivent pouvoir analyser le code.
*Une ressource est quelque chose qu'il vous faut acquérir, utiliser, puis libérer. Par exemple une mutex, un fichier, une socket, et bien entendu de la mémoire.
Le C++ est définitivement expert-friendly, mais pas seulement expert-friendly. Il doit être accessible aux débutants.
Qu'offre le C++ ?
- Pas la perfection : celui qui vous décrit un langage comme parfait est soit un commerçant, soit un fou, soit les deux ;
- Pas tout pour tout le monde ;
- Un modèle fondamental solide ;
- 30+ ans d'affinage dans des conditions réelles : ça marche et on connait ses défauts, si on se jette sur des langages tout neufs qui ont l'air parfaits, c'est en réalité que l'on n'a pas encore eu le temps de trouver leurs défauts ;
- Des performances
- De la stabilité sur le long terme, oui, c'est une véritable fonctionnalité qui permet d'économiser du temps et de l'argent.
Si vous comprenez int et vector, vous comprenez le C++. Le reste n'est que "détails" (1300+ pages de détails toutefois).
Le C++ en 4 slides :
- Il se colle directement au hardware : vous avez des valeurs avec leurs opérations primitives, et des objets qui peuvent être composés par simple concaténation ;
- Des classes qui ont un constructeur et un destructeur : "Un constructeur établit l'environnement dans lequel les membres vont s'exécuter ; le destructeur annule cette action." ;
- Des classes abstraites et de l'héritage : on propose à l'utilisateur uniquement une interface et on l'éloigne de l'implémentation ;
- Des types et des classes paramétrés : les templates, qui permettent à la fois la programmation générique et le calcul compile-time.
Ce qui n'est pas du C++ :
- Pas de Garbage Collector : non nécessaire et tueur de performances ;
- Pas de sécurité de type garantie pour toutes les constructions, on reste proche du matériel et on veut pouvoir l'exploiter ;
- Pas de machine virtuelle, bien qu'il soit possible d'exécuter du code C++ sur une machine virtuelle si on le souhaite ;
- Pas de gigantesque bibliothèque "standard" : pas d'autorité centrale pour accepter/rejeter/aider l'intégration de bibliothèques ;
- Pas de standard pour les graphiques/GUI, le XML, le web, ...
Programmation générique : les Templates
1980 : utilisation des macros pour exprimer des types et des fonctions génériques.
1987 (et actuellement) on recherche quelque chose qui soit :
- Etrêmement général/flexible : "doit être capable de faire bien plus que ce que je peux imaginer" ;
- Zero-overhead : vector et Matrix doivent être capable de rivaliser avec les tableaux du C ;
- Des interfaces bien spécifiées : surcharge implicite, de bons messages d'erreur, et pourquoi pas de la compilation séparée.
Deux sur trois, ce n'est pas si mal... mais ce n'est pas à la hauteur de ses attentes, aussi a-t-il continué d'y travailler pendant plus de 20 ans.
Les templates utilisent du duck typing en compile-time.
De là vient le problème des messages d'erreur d'une longueur abominable, et d'une difficulté de compréhension tout aussi abominable.
Les templates n'ont pas d'interface claire, la détection d'erreur se fait bien trop tard, les utilisateurs dépendent sur les détails d'implémentation et il ne ressemblent en rien aux autres parties du langage, ce qui engendre des problèmes de maintenance et d'enseignement.
En C++98 on écrit ceci :
Code:
1
2
3
4
5
6
7
8
9
10
| template<typename C>
void sort(C& container);
std::vector<int> vs;
std::list<int> ls;
sort(vs);//ok
sort(ls);/*insérer ici votre liste préférée (50+ messages de préférence) de
détails d'implémentations templates qui vous expliquent qu'une
ligne obscure n'est pas compilable*/ |
Avec les concepts-lite de C++14, on écrira ceci :
Code:
1
2
3
4
5
6
7
| void sort(Sortable& container);
std::vector<int> vs;
std::list<int> ls;
sort(vs);//ok
sort(ls);//error: 'std::list<int>' does not satisfy the constraint 'Sortable' |
Et en activant une option du compilateur, il vous dira très clairement que std::list n'est pas Sortable parce qu'il n'est pas Random_Access parce qu'il ne trouve pas d'operator[].
B. Stroustrup expose durant sa conférence les détails des règles (plutôt simples) qui permettent d'écrire des concepts.
"Je n'aime pas le mot 'Paradigmes'"
La plupart des distinctions entre la POO, la programmation générique, et la "programmation conventionnelle" est une illusion :
- due à la focalisation sur des fonctionnalités particulières du langage ;
- un paradigme seul ne peut être complet ;
- cela limite les programmeurs, les forçant à faire du mauvais code et des workarounds.
Ce sont seulement différents aspects que vous pouvez utiliser en combinaison et exprimer du code autrement qu'en termes de paradigmes qui peuvent devenir de stupides religions.
S'agit-il de POO, PG, ou conventionnel ?
Code:
1
2
3
4
5
| void draw_all(Container& c)
requires Same_type<Value_type<Container>,Shape*>
{
for_each(c, [](Shape* p){ p->draw(); });
} |
Réponse : les trois à la fois.
Et vous,
:fleche: Qu'en pensez-vous ?
