Type Erasure : marier la POO et la Programmation Générique

Bonjour,

J'ai publié un article que j'ai écrit à propos du principe de Type Erasure appliqué au C++. Il s'agit d'associer les templates du C++ avec la POO pour résoudre des problèmes bien précis.

Voici le synopsis de l'article.

Citation:

---

Si vous utilisez les templates du C++ pour écrire des composants génériques, vous avez déjà peut-être voulu les combiner à la programmation orientée objet, via de l'héritage par exemple. Peut-être avez-vous eu des difficultés ; cet article va vous présenter une technique répandue, nommée Type Erasure, qui vous permettra de tirer profit des deux mondes sans perdre en flexibilité ni en maintenabilité.

---

http://alp.developpez.com/tutoriels/type-erasure/

C'est une bonne chose, je vais pouvoir approfondir mes connaissances. :ccool:

PS : ( c'est un question, pas un critique ) Pourquoi nous avertir à l'avance ? Tu veux nous rendre impatient ? :lol:

Citation:

---

Envoyé par hiura

C'est une bonne chose, je vais pouvoir approfondir mes connaissances. :ccool:

PS : ( c'est un question, pas un critique ) Pourquoi nous avertir à l'avance ? Tu veux nous rendre impatient ? :lol:

---

C'est pour faire monter l'envie pour que vous dévoriez l'article une fois qu'il est publié :aie:
Et aussi parce que cela permet, lorsqu'on annonce l'article, de lui associer un sujet du forum, afin d'avoir un lien pour le commenter sur http://cpp.developpez.com/ et dans l'article lui-même ;)

Olala ça tease de partout en ce moment sur le forum C++. Bonne nouvelle :). Et ça marche, je vais me ruer dessus quand il sortira ^^.

C'est une technique que je connaissais pas mais en lisant un article sur le net j'ai vite compris que je l'appliquais sans le savoir...

J'attend ton article en espérant qu'il me permette d'affiner ma technique :D

Allez, le sommaire... ;)

Citation:

---

I. Introduction
II. Etude de cas
III. Principe de Type Erasure
IV. Application dans un cas concret
V. Réécrivons boost::any
VI. Limites et conclusion
VII. Remerciements

---

Citation:

---

Envoyé par Alp

Allez, le sommaire... ;)

---

Oh, Alp, tu nous l'offre ? C'est vrai ? T'es trop gentil ! (Surtout que j'ai déjà lu l'article... non, je n'en dévoilerai rien !).

Voilà le lien vers l'article : http://alp.developpez.com/tutoriels/type-erasure/

N'hésitez pas à poster remarques & commentaires ;)

:merci:

Très joli article, Alp !

Je connaissais déjà, mais ça ne peut qu'être bénéfique pour beaucoup de personnes :)

Très intéressant, même si je ne pense pas que j'aurai besoin d'appliquer cette méthode de si tôt (surtout maintenant que j'ai une nouvelle version bien plus jolie de mon type variant héhé).

Merci beaucoup :)

Très bien, c'est bien poussé et en même temps c'est largement abordable. Très bon. Faut que je fasse une deuxième lecture.

Merci à tous, ça fait plutôt plaisir ce genre de réactions :ccool:

Article intéressant mais j'aurais qques points à éclaircir, notamment sur l'exemple concret:

- Quel est l'intérêt ici de paramétrer les composants par des classes de politiques?
- En fait, m' a question est, qu'apporte l'implémentation faite dans l'article de la classe politique?

En plus concret je dirais:
- Si je veux rendre un widget non clickable en clickable? Je fais comment?
- Si je veux ajouter une politique, mettons DragNDrop, je dois modifier toute ma classe widget, je ne trouve pas ça très souple ni paramétrable.

Dans l'exemple du destroy :

Code:

---

1 2 3 4 5 6 7

void destroy() { // ici on fait par exemple DrawingPolicy::destroy(); s'il y a quelque chose à détruire // et autres // enfin, on détruit les widget fils en délégant le travail à widget::destroy widget::destroy(); }

---

Çà suppose que l'implémentation du widget doit avoir connaissance de l'implémentation du DrawingPolicy, pour savoir s'il a qquechose à détruire.. ou alors on appelle destroy pour toutes les policy par défaut..

Code:

---

1 2 3 4 5 6

typedef widget_impl < NonResizable, NonClickAware, ReadOnlyText, SquareDraw > widget_t;

---

et devoir déclarer un typedef pour rendre "utilisable" la classe..
on va finir avec:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

typedef widget_impl < NonResizable, NonClickAware, ReadOnlyText, SquareDraw > widget_NrNcaRotS;     typedef widget_impl < Resizable, NonClickAware, ReadOnlyText, SquareDraw > widget_RNcaRotS;     typedef widget_impl < Resizable, ClickAware, ReadOnlyText, SquareDraw > widget_RCaRotS;   typedef widget_impl < Resizable, ClickAware, EditableText, SquareDraw > widget_RCaEtS;

---

etc etc pour chaque possibilité de widget, et si je rajoute un policy à mon widget(DragNDrop) je devrais reprendre tous mes typedefs pour les modifier...

Enfin je chipote, l'article est très intéressant pour moi, sauf justement toute cette histoire de policy sur les widgets qui (je trouve) n'apporte rien à l'explication et qui (tjs selon mon avis) ne représente pas un bon design dans le cadre de widgets.

J'espère ne froisser personne en disant cela, j espère juste avoir une explication sur l'intérêt de ce design dans le cadre de widgets.

C'est un design comme un autre, qui au lieu de se reposer 100% sur de la variabilité dynamique en met une partie statique. Le principe c'est donc de faire des classes qui implémenteront le comportement de ton widget par rapport à une certaine responsabilité (click, dessin, ...). Si tu veux pouvoir le changer à l'exécution, alors ce n'est pas ce design qu'il faut. (on peut toutefois mixer les deux)

Je te conseille le livre Modern C++ Design, qui est la référence sur les policies.

L'intérêt c'est de découper statiquement les variabilités et aussi de pouvoir combiner des features simplement en donnant les implémentations de politiques correspondantes en paramètre à widget.

Bonsoir Alp,

Tu fais un sacré bon boulot.

À force que tu enfonce le clou, je suis bien obligé de reconnaître que tous les reproches que je suis enclin à faire au C++ (pas assez modulaire, pas assez générique) ont pris un sacré coup de vieux, c'était vrai il y a 15 ans mais on dirait que depuis ça a bien évolué. Il garde encore son côté cryptique mais ça je sais que c'est une réticence qui vient de moi et qui s'estompe si on fait l'effort de s'y mettre.

Citation:

---

Envoyé par SpiceGuid

Bonsoir Alp,

Tu fais un sacré bon boulot.

À force que tu enfonce le clou, je suis bien obligé de reconnaître que tous les reproches que je suis enclin à faire au C++ (pas assez modulaire, pas assez générique) ont pris un sacré coup de vieux, c'était vrai il y a 15 ans mais on dirait que depuis ça a bien évolué. Il garde encore son côté cryptique mais ça je sais que c'est une réticence qui vient de moi et qui s'estompe si on fait l'effort de s'y mettre.

---

Faut s'habituer, c'est certain.
Par exemple, escafr ne semble pas très habitué à ce genre de design (ce n'est pas un reproche, ce n'est pas ta faute !). C'a ses avantages, ses défauts. Tout cela sera mis en avant dans la prochaine mise à jour de la FAQ C++ (j'ai écrit quelques Q/R sur ce genre de choses : les différents types de polymorphisme, etc).

En tout cas, merci pour le compliment, le C++ a effectivement évolué et du coup on essaye de maintenir les ressources C++ à jour :mrgreen:

Au poil ce petit article!
Je ne m'étais jamais vraiment intéressé à ce qui se cachait derrière boost::any! Bien au delà de boost::any ça va m'être vraiment très utile!
Cette solution va résoudre un problème qui va très bientôt se présenter dans mon projet actuel. Merci :ccool:

PS : je crois que l'on attend tous "auto" et le reste avec impatience.. ;)

J'avais juste 2 petites questions :

1/ Je ne comprends pas dans le destructeur de la classe de base widget :

Code:

---

1 2 3 4 5 6 7

virtual ~widget() { if(parent == NULL) widget::destroy();   }

---

Pourquoi tu ecris widget::destroy(); au lieu de this->destroy(). Car sinon, un widget parent n'appellera pas le destroy des sous classes widget_impl dont le destructeur est cense detruire les objets Policies ?

2/ Enfin, pourquoi l'heritage sur les classes Policies est public et non pas prive ? Les policies ne sont pas de la composition plutot que de l'heritage ?

En tous cas merci pour cet article tres instructif pour moi.

Citation:

---

Envoyé par vandamme

J'avais juste 2 petites questions :

1/ Je ne comprends pas dans le destructeur de la classe de base widget :

Code:

---

1 2 3 4 5 6 7

virtual ~widget() { if(parent == NULL) widget::destroy();   }

---

Pourquoi tu ecris widget::destroy(); au lieu de this->destroy(). Car sinon, un widget parent n'appellera pas le destroy des sous classes widget_impl dont le destructeur est cense detruire les objets Policies ?

---

:oops: :aie:

Citation:

---

Envoyé par vandamme

2/ Enfin, pourquoi l'heritage sur les classes Policies est public et non pas prive ? Les policies ne sont pas de la composition plutot que de l'heritage ?

En tous cas merci pour cet article tres instructif pour moi.

---

C'est pour importer automatiquement l'interface des policies dans la classe hôte, et de pouvoir s'en servir à l'extérieur.
En théorie, ce n'est pas 100% génial, mais j'ai préféré ne pas trop surcharger widget_impl avec des fonctions qui appellent directement celles des politiques, pour se concentrer sur le type erasure à proprement parler.

Merci bcp pour tes reponses.

Mais la reponse a la 1ere question ..... je comprends pas.
Le ooops aie est pour moi ou pour toi ?