lmg HS a écrit 166 commentaires

  • [^] # Re: Hum hum…

    Posté par (page perso) . En réponse à la dépêche C++17 libère size(), data() et empty(). Évalué à 3.

    La préconisation d'[Herb Sutter] est d’élargir au maximum l’interface des classes par l’extérieur et de garder membres uniquement les fonctions qui ont besoin d’aller taper dans les membres privés, ou qui peuvent être supplantées par redéfinition (overridding en VO).

    C'est typiquement pas le cas des méthodes size() et data() (pour empty() on peut l'implémenter à partir de size() si la complexité de cette dernière est constante).

    C'est vrai, et c'est là que j'aime bien le commentaire d'Alexander Stepanov qui dit que size() aurait dû être une fonction externe et amie.


    D'un point de vue de la syntaxe, c'est un peu plus compliqué que cela. Dire que a.f(b), b.f(a) et f(a, b) n'est qu'une convention, c'est aller un peu vite… Écrire myValue.addTo(myArray) choque tout le monde quelque soit le langage.

    Presque. Je dis que a.f(b), f(a, b), ou (f a b) ce n'est qu'une convention d'écriture. Un sucre syntaxique.
    Quand je parle de la validité de a.f(b) ou de b.f(a) c'est dans un contexte de dispatch multiple. L'écriture o.f() est intéressante dans nos langages pour dispatcher l'appel à la bonne fonction f() en fonction du type dynamique exact de l'objet o. Mais quand le dispatch dépend du type dynamique de plusieurs objets, pourquoi en choisir un plutôt qu'un autre? On aura parfois, souvent ?, un verbe qui rend un appel plus clair, mais pas toujours. Un exemple type de dispatch multiple : la gestion de collision entre plusieurs objets de natures différentes (vaisseau, missile, astéroïde…). Dans la collision il n'y a pas un objet qui soit plus acteur qu'un autre.


    D'un point de vu pratique il n'est pas pratique d'avoir de l'autocomplétion sur des méthodes libres.

    Il est vrai que la complétion sur des fonctions libres peut s'avérer moins pratique car le lexique des fonctions libres et plus conséquent—même en restreignant le périmètre à toutes les fonctions pouvant matcher des variables dans la portée courante. Si mes souvenirs sont bons, ce point était ressorti lors des échanges autour de l'UCS. Mais il n'avait pas été considéré comme
    critique.


    D'un point de vu lecture, le chainage est plus compliqué de mon point de vu :

    Le chainage o.f().g() respire la vilaine violation de la Loi de Déméter j'ai envie de dire. Quitte à enchainer des transformations de données, je préfère ce qui est fait dans les ranges v3: o | f() | g().


    Je ne suis pas sûr de te suivre concernant ta remarque sur le structural binding. Les concepts ça reste du polymorphisme statique. Dans le cas du dispatch multiple OO, nous sommes sur du polymorphisme dynamique.

  • [^] # Re: std::extend typo?

    Posté par (page perso) . En réponse à la dépêche C++17 libère size(), data() et empty(). Évalué à 1.

    Oui, tout à fait, merci. Je me fais avoir à chaque fois.

    Je suis un complet newbs avec l'interface d'édition des articles sur linuxfr et j'avoue ne pas savoir comment procéder pour corriger cela facilement. '

  • [^] # Re: oups

    Posté par (page perso) . En réponse à la dépêche C++17 libère size(), data() et empty(). Évalué à 3.

    Merci :)

  • # oups

    Posté par (page perso) . En réponse à la dépêche C++17 libère size(), data() et empty(). Évalué à 4.

    Désolé, il y a eu un échec, la dépêche n'était pas prête pour publication. S'il y a moyen de la remettre en édition histoire que je revienne sur un état antérieur publiable, je suis preneur. Merci.

  • [^] # Re: Compilateurs

    Posté par (page perso) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 0.

    (Quelle horreurs ces fautes, et je ne peux plus éditer mon message :-( )

  • [^] # Re: ctags

    Posté par (page perso) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 1.

    Je trouve la configuration de YCM complexe et pas aussi souple que ce que j'aimerai. Typiquement, je bosse sur plusieurs projets en parallèle (produit final + dépendances), et en plus pour chaque projet, je peux choisir le mode (un répertoire en fait) de compilation. Or, avec YCM, c'est l'enfer pour lui dire comment trouver intelligemment, et de façon assez dynamique, où trouver la base de compilation JSON (générée par CMake). Plus des plantages lors de mes dernières utilisations. Ce qui fait qu'au final je suis resté sur ma faim. :(

    Après, je sais plus si YCM souffre des mêmes problèmes que les autres outils passant par libclang -> il faut rajouter des chemins que clang connait (!) pour trouver ses propres fichiers d'en-tête…

  • [^] # Re: Compilateurs

    Posté par (page perso) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 7. Dernière modification le 06/03/17 à 12:17.

    Peut-être parce qu'au delà que c'est un compilateur, clang permet développer quantité d'outils qui vont pouvoir nous assister dans nos tâches quotidiennes, même si la compilation est réalisée avec un compilateur dédié pour ne pas dire exotique parfois.

    Les sanitizers ont été cité. Depuis je n'utilise pratiquement plus valgrind. J'ai plus d'informations et plus vite pour les corruptions du tas. J'ai aussi tous les comportements non définis détectés (à l'exécution). Il y a des furieux qui en train d'écrire un efficiency-sanitizer.

    Côté analyse-statique de code, il y a des trucs classiques via clang-analyse et clang-tidy. Mais aussi un détecteur statique d'inter-blocages et de courses aux données (moyennant annotations). Quantité d'autres outils d'analyse de code source: OCLint, CppDepend… J'ai même croisé une outil de vérification des règles MISRA C et C++—qui donc à l'a différence d'outils tels que Understand a partage son noyau d'analyse des sources, avec un compilateur C++. Ce n'est pas anodin.

    J'ai aussi croisé des outils d'indexation de code ou de refactoring basés sur clang. Plus qu'un IDE a repris ses solutions internes pour travailler sur des codes C et C++ pour des solutions basées sur clang.

    Dans les trucs peu conventionnels, on peut aussi citer Cling, une refonte de Clint (si j'ai bien suivi), qui permet d'interpréter du C++.

    Encore plus tordu, il y templight, un A C++ Template Metaprogram Debugger and Profiler comme ils disent.

    Bref. Clang a initié une révolution dans l'outillage disponible pour travailler en C++. Et il a enrichit le catalogue d'outils pour le C. Et de fait je comprends qu'il soit cité en outillage, chose qui va bien au delà de "un petit compilateur dédié ou restreint à des cas spécifiques". Ce qui me rappelle un machin qui ne sert à rien: un compilateur C écrit (ou plutôt traduit) dans le langage de script de Vim https://github.com/rhysd/8cc.vim. Dans la série, en plus utile, c'est à clang/LLVM que l'on doit les compilateurs C/C++ -> javascripts.

  • # ctags

    Posté par (page perso) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 3.

    A noter que exhuberant ctags (celui qui est dispo dans des paquets) n'a plus donné des signes de vie depuis des années. Il n'a jamais été très bon pour le C++ d'ailleurs, mais toujours mieux que cscope.

    Heureusement, il y a été forké en universal-ctags, qui lui est maintenu. Il a fait des progrès notables côté C++. Il ne saura pas résoudre pour autant les surcharges automatiquement lorsque l'on voudra l'utiliser pour naviguer vers le lieux où un symbole est défini depuis des outils légers tels que Vim.

    Pour ça, il faudra regarder du côté de clang. Il y a plusieurs outils d'indexation et j'avoue ne pas avoir suivi leur état de l'art ces derniers temps pour voir celui qui comprenait le mieux le C++ (toutes versions confondues) tout en n'étant pas trop compliqué à paramétrer.

  • [^] # Re: cppcheck / jenkins / cppunit

    Posté par (page perso) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 3.

    cppunit n'a jamais été très bon. Déjà il y a 20 ans, cxxtest(.sf.Net) avait compris le principe de Don't Repeat Yourself (DRY pour les intimes). Ces dernières années ont été dominées par boost.test et google.test. Et nous avons catch en challenger pas mal du tout.

    A noter qu'ils s'intègrent tous très facilement dans CTest et son (C)Dashboard associé.

  • [^] # Re: Je me lance !

    Posté par (page perso) . En réponse à la dépêche Concours « jeu de mots » et cadeaux pour Noël. Évalué à 3.

    Sauf dans i-- > t[i]. On ne sait pas qui sera évalué en premier: i-- ou t[i].

    Sinon, oui, le principe de la post-décrémentation, c'est de mettre de côté la valeur qui sera utilisée pour la suite et après de décrémenter la variable.

  • [^] # Re: Petits utilitaires pour le grand nettoyage nécessaire du code

    Posté par (page perso) . En réponse à la dépêche Lugaru enfin libre. Évalué à 2.

    Je serai un peu plus violent encore: grep delete et grep free et je les dégage tous pour suivre une approche 100% RAII—le seul endroit où je m'autorise un tel artéfact, c'est dans un destructeur, et il doit y être seul. Aussi, d'après ce que j'ai lu dans les commentaires d'une autre dépêche, vous allez devoir rajouter des petits : private boost::noncopyable (ou équivalent) à toutes les classes de base et à d'autres entités—ceci dit transformer les attributs pointeur en std::unique_ptr aura pratiquement le même effet: détecter les copies qui n'auraient jamais du être permises. Cf FAQ C++ de dvpz au sujet des sémantiques d'entité et de valeur.

    PS: Il existe clang-tidy, clang-analyser, et OCLint en analyseurs FOSS de codes sources. C'est la gamme de produit largement au dessus de ceux qui ont été cités.

  • [^] # Re: euh ?

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 3.

    Quel est le problème avec les constructeurs de copie ? Qu'il faut savoir quand il faut les définir et quand il faut les interdire ? Ce n'est franchement pas très compliqué.

    C'est avant tout un problème de design : savoir distinguer les entités des valeurs, problème qui se pose aussi avec d'autres langages sous d'autres formes: ainsi, cf. les values objects qui ne doivent pas être dérivés en Java (p.ex. un point coloré n'est pas un point, mais il est composé d'un point—cf Effective Java v2).

    Certes en C++, un mauvais design va résulter en un plantage plus vite qu'avec d'autres langages qui vont juste se contenter de nous laisser écrire du code susceptible de produire des résultats aberrants.

  • [^] # Re: questions sur les constructeurs et les vecteurs

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.

    emplace ajoute l'élément qu'il va construire à la volée avec les arguments donnés.

    Je dirais même: directement dans la destination (déjà allouée). Comme le nom l'indique, cela fait de la construction placée avec le new de placement. Mais bon. C'est du détail arcanique. Il est plus important de comprendre dans un premier temps comment on écrit des classes valeurs et savoir distinguer les entités (celles qui n'ont pas besoin d'/ne doivent pas être copiées)—David illustre un cas où le problème peut se poser, celui que tu observes.

  • [^] # Re: questions sur les constructeurs et les vecteurs

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 1. Dernière modification le 15/12/16 à 11:48.

    Si ta classe possède des ressources, il est nécessaire de prévoir comment tu la dupliques. Si tu autorises alors il faut définir le constructeur de copie et l'opérateur d'affectation par copie (plus éventuellement les équivalents en déplacement si tu veux en profiter), sinon, tu interdis. Comment? Réponse dans la FAQ: http://cpp.developpez.com/faq/cpp/?page=Semantique-de-copie

    Dans tous les cas, il te faut un accès au code de ces classes pour spécifier comment la copie et le déplacement se font (ou pas).

  • [^] # Re: Value Semantics Rocks

    Posté par (page perso) . En réponse à la dépêche C++17 garantit le court-circuit de copie (suite de la précédente dépêche). Évalué à 3. Dernière modification le 15/12/16 à 10:21.

    En ce moment ils ont commencé une série de dépêches présentant les évolutions du C++17. Je me suis joint à la troupe pour les quelques sujets que j'avais suivis.

    Ce à quoi tu fais référence a le vent en poupe en ce moment, en particulier suite aux CppCoreGuidelines et à la bibliothèque support GSL. Il a eu de nouvelles tentatives pour faire standardiser des moyens simplifiés pour définir des types opaques en C++. Il y a eu bottage en touche pour le C++17 avec comme argument, utilisez des enum class. Je suis justement en train d'expérimenter sur le sujet, et j'ai une question d'équilibre à trouver (pour définir des positions et des distances pixelliques dans des images: faut-il vraiment deux types ? signed ou unsigned ? …)

    Je m'étais aussi posé la question de définir des types domaines de définition sur des plages réelles, avec objectif à termes de rajouter un chapitre à ma série de billets sur la Programmation par Contrat. J'ai donné le lien il y a deux commentaires de cela—qui pointe vers une autre lib pour avoir des types opaques (ou strong typedef suivant le microcosme d'où l'auteur vient). Je ne suis pas sûr que cela soit vraiment exploitable: il y a un problème de syntaxe, mais aussi un problème de précision de calculs. Il est bien beau de dire que sqrt(1+sin(x)) est toujours défini, mais en pratique 1+sin(x) pourrait être négatif car nous sommes nuls à un epsilon près.

    Dans un gist, j'ai une autre expérience avec des types opaques (sans utiliser des enum class), mais la lib publiée sur reddit est bien plus aboutie.

    EDIT: Pour les libs, il y en a des tonnes. Eigen, mais aussi blaze pour le calcul matriciel avec un syntaxe humaine. HPX qui fait de plus en plus parler de lui pour l'HPC dans le style du standard de 2011—je soupçonne que les évolutions sur la parallélisation en C++2017 viennent de ce projet. Bref. En général, c'est plus dans les communautés dédiées que je vois passer ce genre de sujets : dvpz, zds, voire sdz/oc. La complétion intelligente dépend de l'EDI. La mode est à encapsuler clang aujourd'hui. Cf p.ex. YouCompleteMe pour vim.

  • [^] # Re: Value Semantics Rocks

    Posté par (page perso) . En réponse à la dépêche C++17 garantit le court-circuit de copie (suite de la précédente dépêche). Évalué à 3.

    Le langage n'a pas tant changé que cela de ce côté là. Le SunCC 5 et des bananes que j'utilisais il y a une douzaine d'année (et il était encore plus vieux que ça) m'avait surpris en sachant appliquer du NRVO sur des std::vector.

    Après, les compilateurs… oui, il y a eu de sacrés progrès (ou investissement de ressources humaines et comptables pour certains) de leur côté.

  • [^] # Re: Value Semantics Rocks

    Posté par (page perso) . En réponse à la dépêche C++17 garantit le court-circuit de copie (suite de la précédente dépêche). Évalué à 1.

    Tu peux rajouter Eric Niebler (cf commentaires) à la liste des personnes notables qui préfèrent les signés.

    Pour ma part je suis toujours un peu dubitatif faute d'avoir pris le temps d'explorer toutes les possibilités et désireux d'avoir une garantie de positivité, mais je sens que nous sommes dans un débat du même acabit que NULL VS 0: le machin sémantiquement fort est un gros piège. En ce moment, je suis plus dans le trip de vouloir savoir si de bosser avec des types opaques du niveau domaine de définition va apporter quelque chose en termes de sécurité: https://openclassrooms.com/forum/sujet/types-opaques-domaines-de-definitions?page=1

    BTW, je me trompe ou ton exemple marcherait avec:

    for (std::size_t k = 1; k < point.size(); ++k) {
        draw_line(point[k-1], point[k]);
    }

    Je n'achète pas non plus l'exemple précis du "find_last index qui vérifie v[k] == 0"—sur le github. Probablement parce que ce n'est pas un problème que j'ai fréquemment à résoudre. J'ai rarement besoin de boucler à l'envers.

  • [^] # Re: What you see is not what you get

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.

    NB: il proposait d'utiliser optional<> pour faire plus que la sémantique portée par son nom : il proposait de l'utiliser comme le std::expected<> en cours d'élaboration. Cf mes commentaires dans cette autre dépêche.

  • [^] # Re: What you see is not what you get

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 2.

    L'intégration des VLA n'est-il pas toujours en discussion ?

    On a failli, et puis finalement non. Je n'ai pas suivi ce sujet -> ne pas me demander pourquoi.

  • [^] # Re: What you see is not what you get

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 8.

    Le C++ est clairement un langage que plus on le connait, plus on sait à quel point on ne sait pas grand chose. Mais ce n'est pas très grave. Typiquement, ce genre d'optimisation, ne nous change pas vraiment la vie tant que l'on n'est pas à vouloir optimiser très précisément ce qu'il se passe.

    De plus, et c'est particulièrement vrai depuis le C++11, toutes les choses dans la norme ne sont pas directement pour nous, mais pour des concepteurs de bibliothèques qui pourront nous peaufiner des bibliothèques aux petits oignons qu'il ne nous restera plus qu'à utiliser.

    Tous les utilisateurs de Python n'ont pas forcément conscience des dictionnaires qui sont omniprésents et qui expliquent tout ce qu'il est possible de faire avec le langage, en bien ou en mal. Et pourtant, ils n'ont aucun mal à s'en servir. Ici, ce n'est guère différent.

  • [^] # Re: Remboursez nos invitations !

    Posté par (page perso) . En réponse à la dépêche C++17 exprime la virgule flottante en hexadécimal et offre des cadeaux aux lecteurs de LinuxFr.org. Évalué à 2.

    Je viens d'introduire une note au sujet de l'aliasing, mais c'est vrai, sans le code.

    Sinon, le problème de la portabilité ne se pose AMA que quand on a des constructeurs avec effets de bords et que ces effets de bords sont importants ou lorsque l'on compare par rapport à un mode débug.

    Sinon, le RVO et le NRVO je les avais avec Sun CC 5 (?) il y a plus de 10 ans. Ca serait effectivement malheureux que les compilateurs d'aujourd'hui ne sachent pas faire éluder de façon systématique les cas simples.

  • [^] # Re: Nouveau langage

    Posté par (page perso) . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3. Dernière modification le 08/12/16 à 15:35.

    C'est Alexandrescu, je crois, qui avait pondu un Iterators must go. C'était un des premiers articles de qualité pour pousser vers les remplacement des paires d'itérateurs par des plages (ranges en VO). Entre temps, il est parti vers le D, et je me demande si justement il n'avait pas participé aux ranges en D.

    Bref, la STL v2 est dans cette mouvance. Et sur ce point, nous sommes d'accord, les algos de la STL v1 ne sont pas des plus ergonomiques. Ils ont de la souplesse, mais ils l'exigent de nous également.

    C++20 le prochain je pense sinon. Et effectivement, il semblerait plutôt que l'on lorgne du côté des pipe UNIX. Sauf que … au lieu de se contenter d'une monde purement fonctionnel (de variables non modifiables), on traine le boulet OO des états qui sont altérés. D'où le |=. Dans les autres contraintes, il y a les générateurs à la Python. range::ints() et iota() peuvent ainsi générer un nombre (pseudo) infini d'entiers qui seront générés à la volée.

  • [^] # Re: Nouveau langage

    Posté par (page perso) . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 3.

    J'ai tendance à penser que cette limitation n'est pas propre aux différentes implémentations de la POO que tu cites, mais est inhérente au paradigme lui-même : la POO, qui met en avant la notion d'abstraction, c'est de l'abstraction vue par un enfant de quinze ans et à un moment, ça coince.

    J'ai aussi tendance à avoir cet avis, mais dans le doute (car je suis loin de connaitre les langage OO qui flirtent de très près avec le monde fonctionnel) j'ai préféré spécifier un contexte.

  • [^] # Re: Nouveau langage

    Posté par (page perso) . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 5.

    Utiliser la SL a tout à voir avec la programmation générique. Avant de disposer d'un std::vector<>, il faut l'écrire, et après libre à l'utilisateur de s'en servir. Convergeons vers ton exemple (hors STL mais dans la SL) il y a std::basic_string<> ou même std::basic_ostream<>. Très peu ont conscience que ces trucs existent et pourtant ils s'en servent au travers des typedefs std::string, std::ostream, ou carrément via la variable globale std::cout.

    Ces types sont génériques. Si les chaines ne piochent dans le paradigme OO que l'abstraction et l'encapsulation, les flux sont quant à eux plein d'héritage, multiple de surcroit, de points de variations dynamiques (ou comment filtrer à la volée un flux ou l'altérer pour justifier un texte p.ex.), de design pattern Stratégie, et je peux en oublier. Et ? Ils sont totalement génériques sur le type de caractères, et sur les descriptifs des caractères.

    Nous sommes du côté d'une bibliothèque et pas d'un code métier. Et c'est probablement ça qui fait toute la différence. Côté métier offrir de la généricité est moins souvent pertinent. De fait une classe EtatCivil n'a pas grand intérêt à être générique. Côté bibliothèque j'ai pu travailler avec ITK et OTB, là on a des types images dans une hiérarchie avec pourtant un paramètre template pour le type de pixel. On a aussi des hiérarchies encore plus touffues pour dire qu'un truc assimilable à une image peut être une image, un fichier ou une transformation qui va servir à calculer une nouvelle image. Pour le coup ITK utilise des hiérarchies là où la STL (+ std::string) est 100% orientée concepts.

    Concernant sort, là tu bloques sur l'écriture OO mainstream on dirait. Parenthèse OO: Personnellement, je constate ici l'échec de Java qui comme le C++ a des types primitifs, mais qui a introduit un Top Type (type dont tout objet dérive). Résultat le code de divers algorithmes comme sort est dupliqué entre les tableaux primitifs et les collections à accès direct. Python n'a pas ce problème. Il y a un top type chez lui, mais pas de type primitif.

    Côté écriture de sort, la STL v2 est en cours de préparation. Le C++ assume totalement que la généricité est plus adaptée que des hiérarchies compliquées pour des algorithmes. L'écriture qui est sympa c'est sort(v) pourquoi est-ce que cela devrait être v.sort()? Avec CLOS, la syntaxe d'appel est (func x y z). Ce qui rend la gestion du dispatch multiple tout ce qu'il y a de plus naturel. Une petite discussion à ce sujet dans un article que j'avais bien aimé (le lien pointe directement sur le paragraphe qui discute s'il faut écrire kick the dog ou dog the kick).

    Pour en revenir à la STL v2, en plus de l'écriture action::unique(action::sort(vi));, elle va supporter l'écriture vi |= action::sort | action::unique; qui marcheront aussi sur des tableaux natifs ou sur n'importe quel conteneur à accès direct (seulement? je n'ai pas vérifié) qui expose begin() et end() en libre ou en membre.

    Pour la complexité de la STL, je dirai que pour un bonne part c'est une question d'habitude. Pour avoir lu et écouté Stepanov, ce à quoi il a abouti est naturel. Comme en maths, il voit que chaque algo a des prérequis pour être appliqué, à partir de là, hormis les template <typename NomdeConcept1, ... en début de signature, le reste est franchement clair. Après pour le code des implémentations de la SL, il y a la quasi obligation de tout préfixer avec des tirets-bas et la volonté d'auto-adaptativité à la nature des choses manipulées histoire d'optimiser (nous sommes en C++ après tout), ce qui ne rend pas la lecture toujours triviale. Plus des hacks pour éviter de produire des messages d'erreurs trop inintelligibles, plus de la programmation par contrat. Mais est-ce que cela nous concerne vraiment ?

    Je rajouterai aussi pour avoir essayé de jouer à ça dans ma jeunesse que le paradigme OO (tel qu'implémenté en Pascal/Delphi, C++ et Java) est totalement incapable de modéliser correctement les notions de groupes, anneaux et cie quant on commence à vouloir introduire du dispatch multiple dans des fonctions.

  • [^] # Re: Nouveau langage

    Posté par (page perso) . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 2.

    Les projets réels les utilisent tout le temps.
    - Je veux un tableau dans une classe concrète? std::vector<>. C'est générique et je m'en sers.
    - Je veux un truc qui va collecter automatiquement la mémoire ou n'importe quoi d'autre ? std::unique_ptr<>.
    - Je veux trier un tableau ? std::sort()
    - Je veux des images avec des types de pixel générique ? Ca marche aussi.

    On ne va pas faire 100% dans un style et 100% dans un autre. On va prendre le style qui va bien pour un besoin donné. De la même façon que l'on ne va pas dériver pour le plaisir. On compose bien souvent à la place car cela offre plus de souplesse en ouvrant la porte au pattern Stratégie.

    PS: Dans le monde des typeurs de canards cela que l'on nomme juste "polymorphisme" désigne le "polymorphisme paramétrique" qui en C++ correspond aux templates, et qui est statique (en C++).