Outils d'utilisateurs
le_design_des_bibliotheques_en_c_11
Différences
Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.
|
le_design_des_bibliotheques_en_c_11 [2014/03/08 13:12] gbdivers created |
le_design_des_bibliotheques_en_c_11 [2014/03/14 12:48] (Version actuelle) gbdivers |
||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| + | ====== Le design des bibliothèques en C++11 ====== | ||
| + | |||
| Comment concevoir correctement une bibliothèque en C++11 ? Eric Niebler essaie de répondre à cette question dans une présentation lors du dernier Meeting C++. | Comment concevoir correctement une bibliothèque en C++11 ? Eric Niebler essaie de répondre à cette question dans une présentation lors du dernier Meeting C++. | ||
| Ligne 11: | Ligne 13: | ||
| - les modules | - les modules | ||
| - | ====== Il faut penser nos codes en termes de bibliothèques (diapo 5) ====== | + | ===== Il faut penser nos codes en termes de bibliothèques (diapo 5) ===== |
| Une bibliothèque "est une collection d'implémentation de comportements, écris en termes de langage, qui possède une interface bien définie permettant d'invoquer ces comportements. [...] Le comportement est prévu pour la réutilisation [...]." (traduction de Wikipedia, "Library (software)", Octobre 2013, cité dans la présentation). | Une bibliothèque "est une collection d'implémentation de comportements, écris en termes de langage, qui possède une interface bien définie permettant d'invoquer ces comportements. [...] Le comportement est prévu pour la réutilisation [...]." (traduction de Wikipedia, "Library (software)", Octobre 2013, cité dans la présentation). | ||
| Ligne 17: | Ligne 19: | ||
| Cette définition devrait correspondre à tous les codes que l'on écrit et donc tous les codes que l'on écrit devrait être des bibliothèques :) (je simplifie un peu l'idée). | Cette définition devrait correspondre à tous les codes que l'on écrit et donc tous les codes que l'on écrit devrait être des bibliothèques :) (je simplifie un peu l'idée). | ||
| - | ====== Le design des fonctions (diapo 14) ====== | + | ===== Le design des fonctions (diapo 14) ===== |
| * Est-ce que ma fonction est facile à appeler correctement ? | * Est-ce que ma fonction est facile à appeler correctement ? | ||
| Ligne 34: | Ligne 36: | ||
| - Guideline 3 : encapsulez les états d'un algorithme dans un objet qui implémente cet algorithme. | - Guideline 3 : encapsulez les états d'un algorithme dans un objet qui implémente cet algorithme. | ||
| - | ====== Le design des classes (diapos 37 et 38) ====== | + | ===== Le design des classes (diapos 37 et 38) ===== |
| * Comment concevoir une classe en C++11 qui utilise au mieux le C++11 ? | * Comment concevoir une classe en C++11 qui utilise au mieux le C++11 ? | ||
| Ligne 61: | Ligne 63: | ||
| - Corollaire : tous les types déplaçables doivent avoir un état valide par défaut, peu coûteux à construire. | - Corollaire : tous les types déplaçables doivent avoir un état valide par défaut, peu coûteux à construire. | ||
| - | ====== Le design des modules (diapos 56) ====== | + | ===== Le design des modules (diapos 56) ===== |
| Pour le design des modules, Eric Niebler fait un constat simple : le C++11 offre peu de fonctionnalités pour garantir la création de modules évolutifs et réutilisables. Que peut-on attendre d'un langage pour cette problématique ? | Pour le design des modules, Eric Niebler fait un constat simple : le C++11 offre peu de fonctionnalités pour garantir la création de modules évolutifs et réutilisables. Que peut-on attendre d'un langage pour cette problématique ? | ||
| Ligne 79: | Ligne 81: | ||
| - Guideline 11 : préférez des objets-fonctions globaux constant (constexpr) aux fonctions libres nommées (sauf pour les points de personnalisation documentés). | - Guideline 11 : préférez des objets-fonctions globaux constant (constexpr) aux fonctions libres nommées (sauf pour les points de personnalisation documentés). | ||
| - | ====== Conclusion ====== | + | ===== Conclusion ===== |
| On voit bien avec cette présentation en quoi le C++11 nécessite de changer ses habitudes de codage si on souhaite améliorer l'évolutivité de ses codes, mais aussi le travail qui reste à faire pour améliorer encore le C++. La transition peut se faire en douceur, puisque le C++ reste rétro-compatible (un code ancien continuera de fonctionner). L'idéal est donc de faire évoluer le code existant (en totalité ou en partie) à l'occasion d'une maintenance ou d'une évolution. Il ne faut pas non plus avoir peur de repenser l'architecture globale de son code (la difficulté étant de réussir à "oublier" l'architecture existante pour trouver la "bonne" architecture et pas simplement mettre des pansements sur une architecture bancale). | On voit bien avec cette présentation en quoi le C++11 nécessite de changer ses habitudes de codage si on souhaite améliorer l'évolutivité de ses codes, mais aussi le travail qui reste à faire pour améliorer encore le C++. La transition peut se faire en douceur, puisque le C++ reste rétro-compatible (un code ancien continuera de fonctionner). L'idéal est donc de faire évoluer le code existant (en totalité ou en partie) à l'occasion d'une maintenance ou d'une évolution. Il ne faut pas non plus avoir peur de repenser l'architecture globale de son code (la difficulté étant de réussir à "oublier" l'architecture existante pour trouver la "bonne" architecture et pas simplement mettre des pansements sur une architecture bancale). | ||
| + | |||
| + | {{tag> C++11}} | ||
le_design_des_bibliotheques_en_c_11.1394280777.txt.gz · Dernière modification: 2014/03/08 13:12 par gbdivers
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante : CC Attribution-Noncommercial-Share Alike 3.0 Unported
