Discussion :

[gorgonite]

Problème avec une hiérarchie de classes, tu fais comment pour rajouter des nouvelles fonctions?
Une hiérarchie de classe est ouvert pour l'espace des types, mais fermé pour les algorithmes.

L'interface d'une classe mère, c'est quelque chose de fermé. La solution c'est de faire un visiteur, et du coup on bloque l'espace des types.

Et ça revient à faire Boost.Variant en moins bien.

que veux-tu dire par ajouter des fonctions ?

si tu parles de la déclaration de blocs de code correspondants à une fonction dans le langage "parsé", il suffit de concevoir la déclaration d'une fonction, comme une phase de déclaration quelconque... faut juste savoir à quel niveau l'intégrer (ça dépend des langages), idem pour les lambda-expressions

si tu parles d'ajout d'algos de traitement sur ton CFG, ce n'est pas vraiment compliqué... avec une méthode handle, et une classe VirtualTask dérivée pour chaque algo à appliquer

dans les deux cas, ça se fait bien... et la solution boost::variant me semble beaucoup moins extensible


après clairement, si tu dois gérer ta mémoire (C++ donc ), il est clair qu'il ne faut pas utiliser des pointeurs "à la C", mais des choses plus subtiles...

[Alp]

après clairement, si tu dois gérer ta mémoire (C++ donc ), il est clair qu'il ne faut pas utiliser des pointeurs "à la C", mais des choses plus subtiles...

i.e ce que tout bon programmeur C++ fait de nos jours

[gorgonite]

i.e ce que tout bon programmeur C++ fait de nos jours

j'ai jamais dit le contraire...

je dis juste que j'avais la flemme de le mettre dans mon exemple de hiérarchie de classes

[HanLee]

que veux-tu dire par ajouter des fonctions ?

si tu parles de la déclaration de blocs de code correspondants à une fonction dans le langage "parsé", il suffit de concevoir la déclaration d'une fonction, comme une phase de déclaration quelconque... faut juste savoir à quel niveau l'intégrer (ça dépend des langages), idem pour les lambda-expressions

si tu parles d'ajout d'algos de traitement sur ton CFG, ce n'est pas vraiment compliqué... avec une méthode handle, et une classe VirtualTask dérivée pour chaque algo à appliquer

dans les deux cas, ça se fait bien... et la solution boost::variant me semble beaucoup moins extensible


après clairement, si tu dois gérer ta mémoire (C++ donc ), il est clair qu'il ne faut pas utiliser des pointeurs "à la C", mais des choses plus subtiles...

CFG ?

Je voulais dire : ajouter une fonction qui prend un 'a ast en paramètre.

En OCaml, si tu as un type somme, tu peux ajouter facilement de telles fonctions. Mais tu ne peux pas rajouter facilement des "sous-types" à 'a ast.

En C++, avec une hiérarchie de classe, de manière simpliste, tu fais des fonctions virtuelles. Mais naïvement, l'ensemble des fonctions virtuelles est statique et non extensible.
Par contre, tu peux ajouter autant de sous-types que tu veux. En CAML, tu ne peux pas faire ça.

La solution typique OO c'est le visiteur.

Si je comprend bien, c'est l'équivalent ta méthode Handle() qui prend en argument ta classe abstraite VirtualTask.
Du coup, tu ne peux plus ajouter de nouveau sous-type à la hiérarchie de classe (sans modifier VirtualTask).

Et là j'ai dit que ça revient à faire Boost.Variant.
On a pas forcément besoin de créer nos propres classes non plus (à part pour les algorithmes).

Exemple : boost::variant<int, std::string>.

[LLB]

Merci pour l'exemple !

Par contre, il s'agissait bien de vous montrer que le C++ est un chouilla sous-estimé et ramené au niveau de Java/C# pour beaucoup de choses, à tort

Oui, je n'ai pas l'habitude de Boost, mais je connais assez bien le reste (ce qui est en standard : les fonctionnalités du langage et la STL).

Pour C#, c'était un langage pourri il y a quelques années, mais il y a eu beaucoup d'améliorations depuis. Ce n'est pas la peine de relancer le troll C# / C++, mais C# se défend vraiment bien maintenant (même s'il n'a pas les templates).

[gorgonite]

CFG ?

cfg = control flow graph

Si je comprend bien, c'est l'équivalent ta méthode Handle() qui prend en argument ta classe abstraite VirtualTask.
Du coup, tu ne peux plus ajouter de nouveau sous-type à la hiérarchie de classe (sans modifier VirtualTask).

Et là j'ai dit que ça revient à faire Boost.Variant.
On a pas forcément besoin de créer nos propres classes non plus (à part pour les algorithmes).

Exemple : boost::variant<int, std::string>.

non, ce n'est pas ce que je voulais dire... et inutile de dire que tout revient boost:variant sinon je vous ressors mon troll sur tout revient à void*


je reviendrais dessus quand j'aurais du temps

[HanLee]

non, ce n'est pas ce que je voulais dire... et inutile de dire que tout revient boost:variant sinon je vous ressors mon troll sur tout revient à void*

C'est ce que j'ai compris qui revenait, à Boost.Variant.

je reviendrais dessus quand j'aurais du temps

Ah bah excuse-moi, on t'attend.

----------------------

PS : de toute façon, je montre cette solution Boost.Variant, mais j'aime pas ça. C'est imbitable.

J'ai un projet personnel sur de la manipulation d'expression arborescentes intuitive, j'ai commencé à faire un arbre avec Boost.Variant. C'était déjà dégueu, et au moment de faire les algorithmes, j'me suis vite réfugié vers OCaml.

Pour :
- son pattern-matching et donc du code concis
- ses temps de compilation
- l'interpréteur interactif
- des erreurs de compilation plus clairs.

Pour un petit module avec des algorithmes pas compliqués, Boost.Variant est envisageable, ou bien avec un type non récursif.

[InOCamlWeTrust]

Et en FORTRAN 77 on fait comment ?

[Alp]

Pour C#, c'était un langage pourri il y a quelques années, mais il y a eu beaucoup d'améliorations depuis. Ce n'est pas la peine de relancer le troll C# / C++, mais C# se défend vraiment bien maintenant (même s'il n'a pas les templates).

Oui c'est vrai que c'est sympa. Mais les templates ça manque
D'un autre côté, il est bien pour ce qu'on lui demande de faire

Et en FORTRAN 77 on fait comment ?

TU FAIS PAS

[gasche]

En OCaml, si tu as un type somme, tu peux ajouter facilement de telles fonctions. Mais tu ne peux pas rajouter facilement des "sous-types" à 'a ast.

En C++, avec une hiérarchie de classe, de manière simpliste, tu fais des fonctions virtuelles. Mais naïvement, l'ensemble des fonctions virtuelles est statique et non extensible.
Par contre, tu peux ajouter autant de sous-types que tu veux. En CAML, tu ne peux pas faire ça.

Si, avec des variantes polymorphes :
http://caml.inria.fr/pub/papers/garr...use-2000.ps.gz

[SpiceGuid]

C'est rare qu'on veuille à la fois l'extensibilité pour les fonctions et pour les données, mais au cas où les variants polymorphes ont été conçus pour ça.

[Garulfo]

[...]C# se défend vraiment bien maintenant (même s'il n'a pas les templates).

D'un autre côté, les templates ont été fait pour surmonter les limitations au point de vue réflexivité en C++. Smalltalk n'avait pas ce problème. Si je ne me trompe pas C# ne l'a pas non plus. Attention, je ne dis pas que l'un est meilleur que l'autre et je ne dis pas que les templates en sont restés au même stade depuis.

[InOCamlWeTrust]

C'est rare qu'on veuille à la fois l'extensibilité pour les fonctions et pour les données, mais au cas où les variants polymorphes ont été conçus pour ça.

Plus simple et plus beau : l'héritage et la programmation objet.