Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires. Si je dois gérer mes observateurs à la main, je vais utiliser les classes génériques standards. Ne pas le faire serait totalement idiot de ma part.
Pareil, pour gérer la mémoire, par défaut je vais utiliser des unique_ptr<> qui sont génériques. Et je les mettrai dans des objets.
Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué à la lourdeur de la syntaxe et à qui l'école n'a appris qu'un bout de l'OO (pour factoriser des données de bases de données et non pas pour factoriser des comportements) et du procédural. Mais pour la majorité d'entre nous, on n'a rien de tel à écrire. Juste à utiliser.
Reste que ce ne sont pas des paradigmes opposés.
Je dirai aussi, que le mélange est tout sauf récent. Cf la Thèse de Jim O Coplien qu'il a ultérieurement édité en livre: Multiparadigm Design in C++—cf la FAQ de dvpz pour les liens. Un des aspects les plus intéressants, c'est toute la partie sur la dualité commonalities et variability points. C'est le B à ba. On a des zones de code communes, et dedans, il y a des points où des détails vont varier. Et ça on sait le faire depuis longtemps: socket win32 ou socket POSIX ? Tableau d'entiers ou tableau de doubles ? Affichage de carrés, cercles, polygones ou autre figure géométrique ?
Toute la question est la dynamicité derrière les points de variations—et leur potentielle capacité à évoluer sans requérir de modification. Est-ce quelque chose que l'on sait déterminer dans le code source ? En fonction de la plateforme de build ? Est-ce lié à des plugins (choix du .so à charger)? Est-ce totalement dynamique ? Et bien en fonction de ça, ou va jouer avec des #if, on va compiler un .c ou un autre, on va avoir des instances d'un type ou d'un autre, ou on va choisir le paramètre template d'un type générique.
Bref. C'est juste un autre levier qui offre plus de finesse. Et dans un même projet, il peut être intéressant de disposer de plusieurs façons pour procéder.
[^] # Re: Nouveau langage
Posté par lmg HS (site web personnel) . En réponse à la dépêche C++17 branche à la compilation (`if constexpr`). Évalué à 6.
Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires. Si je dois gérer mes observateurs à la main, je vais utiliser les classes génériques standards. Ne pas le faire serait totalement idiot de ma part.
Pareil, pour gérer la mémoire, par défaut je vais utiliser des
unique_ptr<>qui sont génériques. Et je les mettrai dans des objets.Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué à la lourdeur de la syntaxe et à qui l'école n'a appris qu'un bout de l'OO (pour factoriser des données de bases de données et non pas pour factoriser des comportements) et du procédural. Mais pour la majorité d'entre nous, on n'a rien de tel à écrire. Juste à utiliser.
Reste que ce ne sont pas des paradigmes opposés.
Je dirai aussi, que le mélange est tout sauf récent. Cf la Thèse de Jim O Coplien qu'il a ultérieurement édité en livre: Multiparadigm Design in C++—cf la FAQ de dvpz pour les liens. Un des aspects les plus intéressants, c'est toute la partie sur la dualité commonalities et variability points. C'est le B à ba. On a des zones de code communes, et dedans, il y a des points où des détails vont varier. Et ça on sait le faire depuis longtemps: socket win32 ou socket POSIX ? Tableau d'entiers ou tableau de doubles ? Affichage de carrés, cercles, polygones ou autre figure géométrique ?
Toute la question est la dynamicité derrière les points de variations—et leur potentielle capacité à évoluer sans requérir de modification. Est-ce quelque chose que l'on sait déterminer dans le code source ? En fonction de la plateforme de build ? Est-ce lié à des plugins (choix du .so à charger)? Est-ce totalement dynamique ? Et bien en fonction de ça, ou va jouer avec des
#if, on va compiler un .c ou un autre, on va avoir des instances d'un type ou d'un autre, ou on va choisir le paramètre template d'un type générique.Bref. C'est juste un autre levier qui offre plus de finesse. Et dans un même projet, il peut être intéressant de disposer de plusieurs façons pour procéder.