Modéliser une routine (fonction ou procédure)

Version imprimable

15/12/2006, 01h05
koala01

Modéliser une routine (fonction ou procédure)
Salut,

Je sais bien que ce message aurait sans doute été plus à sa place dans un forum plus généraliste, mais, comme il ne s'agit pas vraiment d'algorithmie, et que la méthode de modélisation m'importe peu, ben, voilà, je poste dans le forum dédié au langage qui sera utilisé...

Mon but est d'arriver à modéliser correctement l'ensemble de ce qui peut créer une fonction ou une procédure de langage de programmation.

Entendons nous bien, il ne s'agit nullement d'essayer d'interpréter cette procédure, simplement, de pouvoir gérer "de manière logique" son contenu, à savoir, créer un "arbre Naire" dont la racine serait la déclaration de la routine en elle meme (avec le nom, le type de retour, la liste des arguments et la liste des variables qu'elle connait) et dont le noeud enfant contiendrait le bloc d'instructions que la routine doit effectuer.

Par instruction, j'entend
- Les commentaires, prévus pour etre multilignes dés le départ
- les appels de fonctions existantes (avec ou sans récupération de la valeur renvoyée)
- les différents types de boucles (for, while, do...while) avec les parametres qui leur conviennent
- les tests Vrai faux (if... else) avec les parametres qui leur conviennent
- les tests à choix multiple (switch... case) avec les parametre qui leur conviennent...
Evidemment:
- les boucles doivent etre en mesure d'accepter un bloc d'instructions à effectuer,
- les tests vraix faux doivent etre en mesure d'accepter deux blocs d'instructions (un pour le if et l'autre pour le else) et
- les tests à choix multiples doivent etre en mesure d'accepter une liste de N bloc d'instructions, correpondant à l'ensemble des "case" envisagés (un bloc d'instruction par case)
Sans oublier que, si bloc d'instruction il y a, il s'agit de pouvoir en ajouter, en retirer, accéder à l'une ou l'autre instruction, voire, en intervertir deux à notre guise, ni que, si liste de bloc d'instructions il y a, il s'agira de pouvoir non seulement accéder à chaque bloc d'instruction de la meme manière, mais aussi de pouvoir rajouter/retirer un bloc d'instruction à n'importe quel moment

Enfin, pour corser le tout, il s'agirait de pouvoir, à tout moment, récupérer la liste des variables et des arguments déclarés, de manière à vérifier la présence de ce qu'on aurait présenté comme étant "une variable", quitte à remonter de "parent" en "parent" pour retrouver la racine de l'arbre

L'astuce, c'est que si j'ai une idée précise de ce qui doit composer chaque élément pris séparément, des méthodes qui "iront bien" avec, je n'arrive pas à déterminer "la meilleure" (ou en tout cas, la moins mauvaise) solution pour faire de manière à ce que tout ce beau monde puisse cohabiter harmonieusement au sein d'un seul et même bloc d'instructions.

C'est pourquoi je me tourne vers vous: quelqu'un aurait-il une idée sur la manière d'organiser tout cela :question:

Merci d'avance, et, surtout, merci d'avoir eu le courage de me lire jusqu'au bout...
15/12/2006, 01h24
loufoque

Tu veux parser du C++ ?
15/12/2006, 01h28
HanLee

On dirait même que tu voudrais modéliser l'arbre sémantique, plus que parser simplement.

Justement, non...

Je veux, au contraire, disposer d'un ensemble de classes qui permette de maintenir les informations, il n'est nullement question d'interpréter un langage quelconque, il est juste question de pouvoir "recréer l'arborescence" de l'algorithmie...

L'idée est bel et bien de juste arriver à un résultat ressemblant à
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 nomroutine | returntype (type de retour) | varlist (liste des variables connues, y compris les arguments |--Instruction 1 (commentaire, par exemple) |--boucle1 (pour i = 1 à 13) | |-- instruction 2 (n'importe quoi) | |-- si (test) | | |--alors | | | |--truc | | |--sinon | | | |--brol |--Selon ( mavar) | |--case(val1) | | |--instruction 3 | | |--instruction 4 | |--case(val2) | | |--machin | | |--bidule |--instruction 5
que ce soit tout à fait indépendant du langage, meme si, sur base de l'abre généré on soit en mesure, de générer, finalement, n'importe quel langage procédural...(**)

Citation:

Envoyé par HanLee

On dirait même que tu voudrais modéliser l'arbre sémantique, plus que parser simplement.

Mieux meme, je ne veux pas parser quoi que ce soit... je veux juste modéliser l'arbre sémantique/procédural...

L'idée au final étant d'intégrer cela dans une application dont le but est de sortir un algorithme de type "nassichneiderman" dont l'utilisateur sera libre de créer la logique (avec un certain controle de la logique suivie, mais le problème ne se trouve pas encore là...)

[EDIT](**)Mais ca, c'est encore beaucoup plus loin dans la conception[/EDIT]

15/12/2006, 02h17
alskaar

tu devrais regarder les théories sur les langages et la grammaire utilisé pour
parser du C

si tu regardes les tokens utilisés dans ces grammaires tu devrais pouvoir ressortir les feuilles et les branches du langages ... et donc les objets et interactions entre que tu dois developper.

(Recherches éventuellement a LEX et YAK)
15/12/2006, 02h21
HanLee

Mais comment tu veux faire ça sans parser le code ?

Ou alors il faudrait modifier chaque ligne de code...

Par exemple :

int add(int a, int b)
{
return a + b;
}

devient...

Un truc à base de templates, d'arbre d'expression syntaxique. J'ai une idée dans ma tête mais ce serait super compliqué à mettre en oeuvre.
15/12/2006, 02h55
koala01

je ne sais plus comment le dire...

Il n'est là aucunement question de parser quelque langage que ce soit...

Il est juste question d'obtenir un arbre Naire dont les noeuds peuvent etre de différents types qui dérivent tous d'une classe mere identique, et de savoir quelle est la meilleure manière d'imbriquer tous ces types dans le développement des classes, le tout, en étant en mesure de récupérer relativement facilement le type d'un noeud quelconque auquel on aurait accéder, et de pouvoir accéder aux méthodes qui lui sont propres.

Il ne s'agit ni de récupérer les mots clé propres à un langage ou à un autre, ni d'interpréter ce qui est fait, il s'agit juste de créer l'arbre de la logique qui est suivie, le tout, en vérifiant, si possible, que la logique reste correcte (qu'on n'essaye pas, par exemple, de modifier une variable qui n'aurait pas été déclarée)

Citation:

Envoyé par HanLee

Mais comment tu veux faire ça sans parser le code ?

Simplement parce qu'il n'y a pas de code à parser...

Ce qu'il y a en définitive, c'est un gus devant son écran qui dit:

Citation:

"je vais créer la fonction brol...

(il crée la fonction: la racine de l'arbre)

Citation:

Cette fonction prendra tel et tel parametre, et renvera telle valeur

(il ajoute les parametres à la fonction et indique le type de retour)

Citation:

j'ai besoin de telle et telle variable pour travailler,

(il ajoute les variables auxquelles il a pensé)

Citation:

et avec le tout je fais:
je teste d'abord si bidul vaut 1,

(il ajoute un noeud enfant de type "test vrai faux")

Citation:

et si c'est le cas, je fais ceci,

(il ajoute "fais ceci" dans la partie "vrai" du test)

Citation:

sinon, je fais cela

(il ajoute "fais cela" dans la partie "faux" du test)

Citation:

Puis, j'entre dans une boucle de 1 à autant

(il crée un deuxième enfant de type "boucle pour", avec le nom de la variable à utiliser comme compteur et les valeurs de départ, d'arrivée et de pas)
et dans cette boucle je fais un test de type choix multiple sur bidule(ce qui correspond à un switch case en C)
Sauf qu'à ce moment, l'application lui rétorque

Citation:

Envoyé par APPLICATION

"imbécile, je ne connais pas bidule"

(il crée un enfant de type "choix multiple" dans la boucle)
il le donc rajoute dans la liste des arguments...puis, réflexion faite, se dit qu'il devrait etre passé en tant que premier argument, ben, qu'à cela ne tienne, il le déplace en tant que premier argument
Il réessaie de créer son choix multiple sur bidule, et là, tout le monde est content...

Citation:

L'une des valeurs possible de bidule est trois

(il ajoute un bloc d'instructions à effectuer si bidule vaut 3)

Citation:

si bidule vaut trois, je fais ceci, ca et ca

(il rajoute les trois actions dans le bloc d'instruction dédié à la valeur 3 pour bidule
...

Pour ce qui est de la vérification d'une logique stricte, je n'ai aucun problème...

A aucun moment, il n'est question que l'utilisateur final n'entre la moindre ligne de code, quel que soit le langage utilisé :P

Le problème est, surtout, d'arriver à créer les différentes classes qui rentrent en jeu de manière la plus logique et la plus efficace qui soit...
15/12/2006, 03h03
koala01

En fait, pour l'instant, mon problème est de mettre au point un arbre Naire suffisemment robuste, et qui puisse supporter les différentes possibilités...

J'avais déjà fait un premier jet de l'application à laquelle je pense (pas mal réussi, d'ailleurs), mais toute la gestion de l'arbre passait par un "TTreeView" sous borland builder, avec le problème connexe que quand l'utilisateur introduisait dans un formulaire dédié à la "boucle pour" qu'il voulait utiliser tellle variable avec telle valeur de départ et telle valeur d'arrivée, on obtenait une chaine "pour i = depart à arrivée ", tres facile à placer dans un algorithme, soit, mais...

D'abord, il y a un problème de portabilité, et, ensuite, c'est pas évident à transformer dans différents langages :P

Ah d'accord j'ai compris !

Bah tiens c'est marrant, moi j'voudrais aussi faire un truc comme ça mais de manière graphique, en manipulant des boites, diagrammes, ce qui serait plus simple à visualiser que du code aussi...

Je pense que tu devrais d'abord concevoir une grammaire comme les langages fonctionnels, c'est plus simple à modéliser, tout est expression et toute expression peut être évaluée.

Regarde celle de LISP, c'est super court ici.

Si on s'inspire de Caml, tout entier, caractère, string, float, appel de fonction est une expression d'abord.
Pour les définitions de variables/fonctions, il y a 2 distinctions :
- les définitions sous forme de variables/fonctions globales, qui ne sont pas vraiment des expressions à proprement parler
- les définitions liées, c'est à dire qu'on donne un nom à une variable/fonction qui va être utilisée dans une expression, qui peuvent donc être évaluées

(Soit x = 3 dans l'expression x + 2) = 5, type Int
(Soit a = 5 dans l'expression (x -> x + a) = (x -> x + 5), type (Int -> Int)

Pour simplifier, on peut peut-être confondre ces 2 notions mais je sais pas si c'est une bonne idée.

Toute expression a un type et une valeur quand tu l'évalues.

Ca peut te donner un truc comme ça peut-être (incomplet) :
Code:

1 2 3 4 5 6 7 8 9 Expression = Constante | Sequence_d'instructions([Expr]) | Var_Def (Id, Expr) | Fun_Def (Id, [args], Sequence_d'instructions) | If_Else (Expr_qui_renvoie_bool, Sequence_d'instructions, Sequences_d'instructions) | While (Expr_booleenne, Sequence_d'instructions) | Appel_fonction (Id, [Expr]) Constante = Int | Float | Char | String | Bool
Etc...

Ya quelques subtilités pour les fonctions qui ont des effets de bord mais on voit le principe.

PS : par contre, comment tu fais pour sauvegarder la définition de ta fonction ? Langage intermédiaire ? Sérialisation binaire :aie: ?

15/12/2006, 04h21
koala01
Les problèmes propres à la grammaire des langage sont déjà dépassés...

En gros (et tres rapide, je l'avoue), on peut considérer la mise au point d'une application selon trois grosses étapes:
1. il me faut l'application qui fait (avec ce qu'il faut qu'elle fasse)
2. création de l'algorithme pour y arriver
3. écriture du code
L'application que j'essaie de mettre au point entre se trouve quelque part entre la première phase et dans la deuxieme, en vue d'aider le programmeur à fournir l'algorithme...

J'ai déjà mis au point un premier jet de cette application, mais, comme je n'en suis pas satisfait (et qu'en plus, j'ai en projet d'y apporter pas mal de modifications), je veux reprendre la conception des classes utiles depuis le début...

Si je retrouve le premier jet dans mes archives, je filerai un lien pour que tu puisse voir à quoi cela ressemble...

Mais l'un des problèmes, c'est que cela tourne exclusivement sous windows, et que ca nécessites certaines dll (que je fournirai)...

C'est l'une des raisons qui m'incitent à repenser l'application...
15/12/2006, 04h23
koala01

j'allais oublier de préciser que, au final, cette application est destinée à etre utilisée en mode graphique, évidemment, mais qu'avant d'en arriver là, je voudrais arriver à avoir mon arbre correctement implémenté, de manière à pouvoir m'en servir comme base :P
15/12/2006, 04h35
HanLee

Mais normalement, si tu as déjà ta grammaire, tout est simplifié non ?
Vu que l'utilisateur ne fait qu'appuyer sur des boutons, remplir des champs, tu construis ton arbre des expressions au fur et à mesure des événements ?

C'est la vérification des types qui pose problème ?
Vérifier qu'aucune variable n'a pas été utilisée avant d'être déclarée ?
Ce genre de chose ?

En fait, je ne veux pas d'un arbre binaire déguisé, avec un mot clé au centre, une variable d'un coté et une autre de l'autre coté...

Pour l'instant, ce que j'envisage s'apparente à ceci:

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
 
class Base
{
    public:
    /*trois fois rien, car elle n'est pas utilisée en tant que telle */
    protected:
   /*membres propres aux reste des classe, entre autres*/
    Base* Parent; /*pour pouvoir remonter l'arborescence */
   /* et quelques fonctions qui, dans un premier temps, remontent
       l'arborescence sous forme de Parent->fonction()
       pour les vérifications les plus fréquentes et qui seront surchargées,
       pour la plupart dans Routine */
};
class Comment:public Base
{
 
    /*tout ce qui va bien pour les commentaires, entre autres */
    private:
        std::vector<std::string> lines;
};
class FunctionCall: public Base
{
    /*il s'agit ici du fait d'appeler une routine, et non de la routine
       que je tente de modéliser
       tout ce qui va bien pour les appels de fonction, entre autre 
       */
    private:
        std::string nom;
        std::map<std::string, SVariable> varlist;
/*les arguments doivent apparaitre dans l'ordre où il sont attendu...
   ce qui interdit l'utilisation d'une map */
        std::vector<SGivenArgument> varargs;
};
class Boucle: public Base
{
   /* là ca se complique... parce que la boucle doit prendre 
     "une liste de chose à faire" qui doit pouvoir contenir n'importe
     quelle chose à faire */
     private:
     /* mais on a au moins les parametres qui permettent de gérer la boucle 
     on peut envisager quelque chose sous la forme de */
     enum TYPEBOUCLE{POUR,TANT,JUSQUE};
     TYPEBOUCLE witchboucle;
     std::vector<std::string> params;
};
class TrueFalsTest: public Base
{
    /* ici, il faut une liste des choses à faire si c'est vrai, une si autre
       pour c'est faux et une liste de parametres permettant de recréer le
        test */
 
};
class MultipleChoiceTest: public Base
{
   /* ici, il faut une liste de listes de choses à faire... car on ne sait
       pas à l'avance combien de valeur l'utlisateur va envisager...
       et pour chaque liste de choses à faire, il faut la valeur envisagée
     */
    private:
        std::string namevar;
};
class Routine:public Base
{
    /* C'est cette classe qui sert de "racine" à l'ensemble
        Enfin... Presque, parce qu'au dessus de cela, il y a un module
        qui peut contenir plusieurs Routines, mais qui n'a pas de
        "liste de choses à faires" (meme s'il a une foule d'autres choses) */
    /* évidememnt, il faut une liste de choses à faire ici aussi */
    private:
        std::string nom; /* le nom de la routine */
/* les informations concernant le type renvoyé */
        SReturnType typerenvoi; 
/* la liste des arguments à fournir à la routine */
        std::vector<SArgument> arglist;
/* la liste des variables déclarées dans la routine
    "plus haut" dans l'arborescence (au niveau "module") on envisage
     d'y mettre aussi les variables déclarées en global
 */
        std::map<std::string, SVariable> varlist;
};

Maintenant, je ne suis pas sur que cette manière d'envisager les choses soit la meilleure (d'ou ma question sur le forum), et, surtout, j'hésite sur la meilleure des solutions pour gérer toutes ces "liste de choses à faire"

L'un dans l'autre, je me demandes si je n'aurais pas intéret à créer une énumération du genre de

Code:

1
2
 
enum WHATISIT{COMMENT,FUNCCALL,BOUCLE,TESTTF,TESTMULT};

et à utiliser un tableau dans le genre de

Code:

std::vector<std::pair<WHATISIT, Base*> > dolist;

de manière à pouvoir me baser sur dolist[x]->first pour savoir en quoi transtyper le pointeur sur Base

Toute la question réside en quelque mots: est ce que cet optique d'organisation des classes semble cohérente et, sinon, comment les organiser différemment :question:

15/12/2006, 06h10
HanLee

Usuellement, comme une grammaire est une structure de données récursive, on utilise ce que tu as fait au début, c'est à dire un composite (je crois que c'est le nom) avec l'association d'un visitor, afin de bénéficier du polymorphisme.

Mais c'est vrai que c'est assez lourd à écrire, c'est pour ça qu'on voit parfois la deuxième méthode s'écrire parfois.

Mais c'est assez décourageant d'écrire ce genre de programme dans les langages qui proposent pas de type Union.
15/12/2006, 06h43
koala01

Il faut bien comprendre que le but de cette partie ci du travail n'est que d'arriver à maintenir de manière cohérente les différentes instructions qu'une routine déclarée par l'utilisateur doit, selon la logique qu'il a choisie, effectuer...

Au delà, vient la gestion de plusieurs routines dans un module, avec la gestion des fichiers externes (sommaire, il faut l'avouer... on ne gere réellement que les modules connexes), la gestion de l'ensemble des fonctions connues par le module (celles qui ont été définies dans les modules connexes et celles, propre au langage/à l'EDI que l'utilisateur aura dit vouloir utiliser), des classes/structures/types (selon le meme ordre d'idées)...

Puis, qu'au delà, il y a la gestion du projet, qui regroupent tous ces modules...

Et qu'en fin de compte, il y a une application graphique qui s'amuse à envoyer des message à tout ce basard (affichage sous forme d'arbre Naire pour la facilité, et affichage de l'algorihme tel qu'il est présenté sur le moment...)

Par la suite, il n'est pas exclu d'envisager la transformation automatique en code (n'importe quel langage)... mais, l'un dans l'autre, ce ne sera pas forcément ce qui est le plus dur...

Voilà, en très gros, l'idée générale du projet...

Mais vu que c'est quand meme relativement important comme conception, je voudrais que la base (cette fameuse "routine") soit le plus cohérente, costaude et portable possible de manière à éviter le chipotage par la suite...(et permettre, pourquoi pas, le portage ultérieur sur d'autres architectures)
15/12/2006, 07h11
HanLee

Alors je garderais ce que tu as fait en premier, le design me semble plus robuste aux modifications.
15/12/2006, 07h19
koala01

Ceci dit, je me demandes dans quelle mesure je ne devrais pas prévoir une classe "convertisseur" qui permettrait, en recevant la pair <WHATISIT, *Base> de récupérer, soit un pointeur du type (whatisit) soit carrément la référence sur l'élément...

Etant donné que c'est, typiquement, une convertion qui se fera à un rythme effrené, ca risque de devenir rapidement utile :P
15/12/2006, 16h48
loufoque

Tu peux regarder du côté de boost.tree pour les arbres.

Je ne suis pas certain que tu m’ai bien compris.
Ma remarque porte sur les noeuds et feuilles de ton arbre Naire. c'est Noeuds sont certainement très proches de ce que peut être une grammaire d’un langage.

Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ligne : rvalue ligne : lvalue operateur= rvalue rvalue :fonction rvalue :constante rvalue : rvalue operateur rvalue operateur : + ,- , *, / operateur= : = constante : int lvalue : variable
Ce qui peut te donner l’envie de faire une classe ligne qui se compose d’une rvalue ou d’un operateur=

l’operateur= lui est forcement compose d’une lvalue et d une rvalue

les operateur,fonction constante sont des formes de rvalue donc faut peut être hériter de rvalue ….

En conclusion si tu lis la grammaire d’un langage simples tu peux sans trop te fatiguer faire ressortir les liens entre chacun des éléments et le traduire en classe

ps : mon exemple est certainement pleins d erreurs !

16/12/2006, 12h47
koala01

Non, non, j'ai très bien compris le principe de la grammaire des langages...

Ce que tu ne semble pas comprendre, c'est que je n'ai aucun besoin de la grammaire du langage...

Il y a une abstraction complete de tout langage de programmation, ici, simplement parce qu'on n'en est pas encore à penser en terme de "langage de programmation"...

Du moins, pas dans un premier temps...

On en est encore à penser à la logique qu'il faudra insufler à l'application (faire le flowchart, le pseudo code ou un usecase particulier en UML)

Le contenu meme de la chaine d'instructions n'a ici qu'un intérêt tout à fait limité...
Il est sauvegardé sous une forme ou une autre parce que ca n'aurait aucun intérêt de ne pas le sauvegarder, mais ce qui importe, c'est de savoir "ici, c'est une boucle, là, c'est un test "vrai faux", ou là un commentaire et tout au fond, là bas, c'est un test à choix multiple...

Les valeurs à introduire dans la boucle, le test ou le commentaire ne sont là "que pour mémoire" (et pour pouvoir les utiliser par la suite, entre autre, pour la génération d'un code)...

J'aurais presque envie de dire que, actuellement, si l'utilisateur veut écrire une boucle "pour chameau égal chimpanzée à éléphant par pas de banane", c'est son affaire...

La seule nuance, c'est que, de fait, chameau, banane, chimpanzée et éléphant seront considéré comme étant des variables, et qu'il faut juste s'assurer qu'elles existent (à part chameau qu'on peut envisager de créer sur le tard)... et qu'elles correspondent à un type donné...

Mais ca, c'est pris en compte, en partie par l'application graphique (la création "sur le tard" de la variable chameau)... et on n'en est pas encore là, et en partie lorsque l'on crée la boucle pour l'insérer dans l'arbre (le fait que chimpanzée, banane et éléphant existent)...

La grammaire du langage, si elle intervient, c'est beaucoup plus tard, quand, apres avoir remplis son arbre, il demande de sortir le contenu de l'arbre en C ou en VB (ou en COBOL, en pascal ou en zimbaweien)

Ce qu'il nous faut pour l'instant, c'est pourvoir dire "monsieur veut créer un test vrai faux... ok, on crée une structure permettant d'avoir une série d'instructions pour le cas ou le test est vrai, et une autre pour le cas où le test est faux, le tout, en enregistrant quelque part ce qu'il veut tester" et on s'arrete là :P

Actuellement, ce qu'il me faut, c'est un arbre, avec sa racine, ses branches et ses feuilles, en sachant que les branches peuvent prendre plusieurs apparences.

La racine sera le prototype de la fonction,
les branche seront les boucles et autres tests,
les feuilles seront toutes ces instructions qui tiennent "en une ligne" (afficher brol)

La gestion du contenu meme des différents éléments, "i don't care", car, tout simplement, ca n'entre que peu dans la constitution de l'arbre...

Je devrai, effectivement à un moment où à un autre m'y attaquer, mais ce sera à l'aide d'un module qui n'a rien à voir avec l'arbre en lui meme, qui le parcourrera et interprétera le contenu de chaque élément...

D'ailleurs, pour etre précis, il y aura plusieurs modules qui le pacrourreront...

Le premier sera de nature à présenter cet arbre sous forme de dessin
les autres seront de nature à présenter cet arbre sous forme de code en langage donné

Citation:

Envoyé par loufoque

Tu peux regarder du côté de boost.tree pour les arbres.

Ca, ca pourrait m'intéresser...Sauf que...

Apres une (rapide) recherche, je n'ai trouvé aucun signe de cette bibliotheque dans boost...

Pourrais tu être plus précis quant à la bibliotheque à utiliser:question:
16/12/2006, 13h35
HanLee

C'est normal y'en a pas =P !

Ce qu'il y a, c'est Boost Graph Library, et comme les arbres sont des cas particuliers de graphes, tu peux songer à les utiliser, mais c'est assez compliqué au début à utiliser... Miles a fait une petite introduction sur le site récemment.

Mais tu pourrais utiliser cette bibliothèque d'arbre, conçue dans l'esprit STL : http://www.aei.mpg.de/~peekas/tree/
16/12/2006, 14h40
loufoque

Citation:

C'est normal y'en a pas =P !

Si si.
Ça a été développé cet été.
17/12/2006, 05h01
Luc Hermitte

Citation:

Envoyé par loufoque

Tu peux regarder du côté de boost.tree pour les arbres.

C'est indépendant, dans le sandbox et autres pojets à l'étude, ou cela fait parti d'autre chose ?
J'ai croisé un adobe.forrest (qui vient avec ASL), mais pas de boost.tree officiel.
17/12/2006, 07h02
loufoque

Ça fait partie des projets SoC
18/12/2006, 06h49
koala01

En définitive, je me suis tourné vers un arbre d'héritage ressemblant à
http://koala01.free.fr/prepa/arbreherit.png en me basant sur le fait que tout "est Base", et en sériant par la suite en fonction du nombre potentiel de listes d'actions possible, le tout en ne plaçant dans base qu'un avis permettant de déterminer le nombre de liste, et, dans le deuxième niveau, un avis permettant de déterminer le type précis de la classe...

Ceci dit, je me demande s'il ne serait pas opportun, vu que d'une certaine manière, il s'agit de sérialiser cet ensemble, de me trouner vers boost::serialize, et ce, d'autant plus qu'à terme, ce devra etre enregistré de différentes manières :question:
20/12/2006, 02h13
Luc Hermitte

boost::serialize n'est pas envahissant. Pas besoin d'avoir une classe mère de toutes choses.
A voir selon ce que tu voudras faire.
20/12/2006, 03h32
loufoque

Pour boost.tree, en fait ils travaillent en ce moment à l'ajouter à TR2.
http://open-std.org/JTC1/SC22/WG21/d...006/n2101.html

Sinon y'a trop de franglais dans ton schéma...