Free Automatons with State and Transitions : soumission d'un projet

**Kaamui** · 09/03/2012, 15h13

Bonjour,

Je viens ici pour vous présenter un code que j'ai fait, et qui va beaucoup me servir sous peu. C'est une classe d'automates générique. Les choix de conceptions sont surement à discuter (comme toujours), et je veux volontiers en discuter, mais il faudra des arguments forts pour que je remanie la partie conceptuelle (bon commencé comme ça, je vais avoir beaucoup de retour...). Entre parenthèses, j'ai pour projet ensuite de m'en servir pour proposer librement des automates de gestion multi-écrans, IA, météo, animations, etc dans les jeux vidéos 2D, d'où le nom.

Ce qui m'intéresse surtout, ce sont les remarques sur la propreté du code, sur les choses que j'aurais pas du faire (comme les _ en début de donnée membre (3DArchi me l'a rappelé déjà), ce que je peux encore faire pour améliorer les performences, pour améliorer la sécurité d'utilisation (je suppose que mon code n'est pas du tout exception-safe, mais je maitrise assez mal le sujet), etc...

je veux rendre ce projet irréprochable. Je compte sur vous pour me dire tout ce qui ne va pas

le tout est en pièce jointe, mais pour les moins courageux, je montre le main que j'ai joint pour tester la bête

Le main n'est là que pour illustrer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
#include <iostream>
#include "Automaton.hpp"
#include <map>
 
using namespace std;
using namespace FAST;
 
typedef State<string> SInt;
typedef Transition<string> TInt;
 
 
int main()
{
 
    Automaton<string> Automate1("Automate 1");
 
    Automate1.NewState(new SInt("Etat Initial", initialState));
    Automate1.NewState(new SInt("Etat 2",       intermediaryState));
    Automate1.NewState(new SInt("Etat 3",       intermediaryState));
    Automate1.NewState(new SInt("Etat 4",       intermediaryState));
    Automate1.NewState(new SInt("Etat 5",       finalState));
 
    Automate1.NewTransitionForState("Etat Initial", new TInt("touche haut","transition vers l'etat numero 2"),   Automate1.GetStateByName("Etat 2"));
    Automate1.NewTransitionForState("Etat Initial", new TInt("touche bas","transition vers l'etat numero 3"),    Automate1.GetStateByName("Etat 3"));
    Automate1.NewTransitionForState("Etat 2",       new TInt("touche gauche","transition vers l'etat numero 4"), Automate1.GetStateByName("Etat 4"));
    Automate1.NewTransitionForState("Etat 3",       new TInt("touche droite","transition vers l'etat numero 5"), Automate1.GetStateByName("Etat 5"));
    Automate1.NewTransitionForState("Etat 4",       new TInt("touche gauche","transition vers l'etat numero 5"), Automate1.GetStateByName("Etat 5"));
    Automate1.NewTransitionForState("Etat 4",       new TInt("touche bas","transition vers l'etat numero 1"),    Automate1.GetStateByName("Etat Initial"));
 
    int compteur = 0;
    cout << "->";
    while(Automate1.GetCurrentState()->GetType() != finalState)
    {
        cout << Automate1.GetCurrentState()->GetName() <<"(";
        const std::string& currentStateName = std::string(Automate1.GetCurrentState()->GetName());
        if (currentStateName == "Etat Initial")
        {
            compteur++;
            if (compteur==10)
            {
                cout << Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 3")->GetValue();
                Automate1.UpdateState(Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 3"));
            }
            else
            {
                cout << Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 2")->GetValue();
                Automate1.UpdateState(Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 2"));
            }
        }
        else if (currentStateName == "Etat 2")
        {
            cout << Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 4")->GetValue();
            Automate1.UpdateState(Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 4"));
        }
        else if (currentStateName == "Etat 3")
        {
            cout << Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 5")->GetValue();
            Automate1.UpdateState(Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 5"));
        }
        else if (currentStateName == "Etat 4")
        {
            cout << Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 1")->GetValue();
            Automate1.UpdateState(Automate1.GetCurrentState()->GetTransitionByName("transition vers l'etat numero 1"));
        }
        else
            cout << "Etat non reconnu" << endl;
 
            cout << ") ->";
    }
    cout << Automate1.GetCurrentState()->GetName() << endl;
 
    return 0;
}

Pour les perfs, je précise que je suis en mode debug, donc ça peut être beaucoup mieux en release je pense (mais je ne constate aucun changement personnellement, à part la taille de l'éxécutable) : le main fait passé un automate dans 30 états en 29ms (chez moi) et 47ms (au boulot)

je pose un bout de code plus concret pour ceux qui n'ont pas le temps :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
 
#ifndef AUTOMATON_HPP
#define AUTOMATON_HPP
 
#include <vector>
#include "State.hpp"
 
 
namespace FAST
{
 
 
 
template<typename T>
class Automaton
{
    public :
        typedef std::vector<State<T>*> T_statesVector;
 
        Automaton(const std::string& name_, const T_statesVector& statesVector_ = std::vector<State<T>*>());
        ~Automaton();
 
        void NewState(State<T>* state_);
 
        const State<T>* GetCurrentState() const;
        State<T>* GetCurrentState();
        void UpdateState(Transition<T>* transition_);
 
        void NewTransitionForCurrentState(Transition<T>* transition_, State<T>* stateReached_);
        void NewTransitionForState(const std::string& name_, Transition<T>* transition_, State<T>* stateReached_);
 
        const State<T>* GetStateByName(const std::string& name_) const;
        State<T>* GetStateByName(const std::string& name_);
 
 
        const std::string& GetName() const;
        std::string& GetName();
        void SetName(const std::string& name_);
 
    private :
        T_statesVector _statesVector;
        std::string _name;
        State<T>* _currentState;
 
};
 
template<typename T>
Automaton<T>::Automaton(const std::string& name_, const T_statesVector& statesVector_) :
_statesVector(statesVector_),
_name(name_),
_currentState(NULL)
{
 
}
 
template<typename T>
Automaton<T>::~Automaton()
{
 
}
 
template<typename T>
void Automaton<T>::NewState(State<T>* state_)
{
    _statesVector.push_back(state_);
    if (_currentState == NULL)
        _currentState = state_;
}
 
template<typename T>
const State<T>* Automaton<T>::GetCurrentState() const
{
    return _currentState;
}
 
template<typename T>
State<T>* Automaton<T>::GetCurrentState()
{
    return _currentState;
}
 
template<typename T>
const State<T>* Automaton<T>::GetStateByName(const std::string& name_) const
{
    typename T_statesVector::iterator it;
    for(it=_statesVector.begin(); it=! _statesVector.end(); ++it)
    {
        if ((*it)->GetName() == name_)
            return it;
    }
    return NULL;
}
 
template<typename T>
State<T>* Automaton<T>::GetStateByName(const std::string& name_)
{
    typename T_statesVector::iterator it;
    for(it=_statesVector.begin(); it!= _statesVector.end(); ++it)
    {
        if ((*it)->GetName() == name_)
            return *it;
    }
    return NULL;
}
 
template<typename T>
void Automaton<T>::UpdateState(Transition<T>* transition_)
{
    if (_currentState->GetTransitionByName(transition_->GetName()) != NULL)
        _currentState = _currentState->GetStateReachedByTransition(transition_->GetName());
}
 
template<typename T>
void Automaton<T>::NewTransitionForCurrentState(Transition<T>* transition_, State<T>* stateReached_)
{
    _currentState.NewTransition(transition_, stateReached_);
}
 
template<typename T>
void Automaton<T>::NewTransitionForState(const std::string& name_, Transition<T>* transition_, State<T>* stateReached_)
{
    typename T_statesVector::iterator it;
    for(it=_statesVector.begin(); it!= _statesVector.end(); ++it)
    {
        if ((*it)->GetName() == name_)
            (*it)->NewTransition(transition_, stateReached_);
    }
}
 
template<typename T>
const std::string& Automaton<T>::GetName() const
{
    return _name;
}
 
template<typename T>
std::string& Automaton<T>::GetName()
{
    return _name;
}
 
template<typename T>
void Automaton<T>::SetName(const std::string& name_)
{
    _name = name_;
}
 
 
 
}

**dragonjoker59** · 09/03/2012, 15h23

Première remarque :
const std::string* currentStateName = new std::string(Automate1.GetCurrentState()->GetName());Déjà, dans ton code il n'y a aucun intérêt de déclarer un pointeur pour ça, de plus tu ne fais jamais de delete => Memory Leaks.
Fais donc comme ceci :
const std::string & currentStateName = Automate1.GetCurrentState()->GetName();Ensuite, pourquoi n'utilises-tu pas un enum plutôt que des chaînes de caractères pour les états de ton automate ? Au niveau des comparaisons tu gagnerais un temps non négligeable.

**Kaamui** · 09/03/2012, 15h50

Envoyé par dragonjoker59

Première remarque :
const std::string* currentStateName = new std::string(Automate1.GetCurrentState()->GetName());

en fait le type de retour de GetName() c'est soit const std::string* soit std::string* et comme je savais que je ne voulais pas le modifier ensuite, j'appelle la méthode const. Le pointeur, c'est juste pour collé au type de retour, j'avais pas envie que ce soit plus moche.

Envoyé par dragonjoker59

de plus tu ne fais jamais de delete => Memory Leaks.

Ah oui, merci. J'ai oublié de faire les Destructeurs ça me fait penser

Envoyé par dragonjoker59

Ensuite, pourquoi n'utilises-tu pas un enum plutôt que des chaînes de caractères pour les états de ton automate ? Au niveau des comparaisons tu gagnerais un temps non négligeable.

pour les états ? sois plus précis... c'est une base générique, le main n'est qu'un test, bien loin de ce à quoi cela va servir le tout.

Si tu parles des types d'état (initial, intermédiaire, final), j'utilise un enum. Sinon mes états sont des string juste pour tester, mais j'avais fait un test avec des int avant (c'est pour cela que dans le main il y a TInt et SInt), et j'ai même un exemple avec une classe Toto.

Edit : ah ok ce sont les touches haut, droite, etc qui t'ont perturbé. C'est juste pour illustrer.

**dragonjoker59** · 09/03/2012, 16h41

Ce ne sont pas les touches haut bas gauche et droite qui m'ont perturbé, mais bien les chaînes de caractères "Etat Initial", "Etat 2", "Etat 3", "Etat 4" et "Etat 5"
Et je pense que retourner un pointeur sur une chaîne n'est pas nécessaire ni spécialement une bonne idée (ce n'est que mon avis, j'essaie d'éviter les pointeurs quand je peux). Je retournerais plutôt une référence constante (ou pas, d'ailleurs) : const std::string & dans mon accesseur

En tout cas si tu passes par un pointeur, ne fais pas de new à cet endroit là, car ça nuit aux performances de ton appli.

**Kaamui** · 09/03/2012, 16h52

Envoyé par dragonjoker59

Ce ne sont pas les touches haut bas gauche et droite qui m'ont perturbé, mais bien les chaînes de caractères "Etat Initial", "Etat 2", "Etat 3", "Etat 4" et "Etat 5"
Et je pense que retourner un pointeur sur une chaîne n'est pas nécessaire ni spécialement une bonne idée (ce n'est que mon avis, j'essaie d'éviter les pointeurs quand je peux). Je retournerais plutôt une référence constante (ou pas, d'ailleurs) : const std::string & dans mon accesseur

En tout cas si tu passes par un pointeur, ne fais pas de new à cet endroit là, car ça nuit aux performances de ton appli.

Ok, c'est noté, pour les performances. Je fais immédiatement cette correction.

Maintenant, est-ce que je pourrais avoir tes réactions (et celle des autres) sur le code qui m'intéresse vraiment ? Dois-je gérer des exceptions? (si oui aurais-tu des conseils?), est-ce que d'autres choses ne vont pas ? etc...

**Ekleog** · 09/03/2012, 20h01

Si le but est d'écrire quelque chose de neuf, je ne dis rien.

Mais, si le but est d'avoir quelque chose d'efficace, à utiliser dans un projet plus grand, je ne peux que conseiller Boost.MetaStateMachine.

**Kaamui** · 09/03/2012, 20h42

Envoyé par Ekleog

Si le but est d'écrire quelque chose de neuf, je ne dis rien.

Mais, si le but est d'avoir quelque chose d'efficace, à utiliser dans un projet plus grand, je ne peux que conseiller Boost.MetaStateMachine.

le but est d'écrire quelque chose de neuf. Des remarques pertinentes sur le projet en lui-même ?? vraiment personne ?

**Kaamui** · 10/03/2012, 09h06

Bonjour,

petite relance... ça intéresse vraiment personne ? c'est une question comme une autre... par exemple comment je fait pour rendre ce projet exception-safe? quelle démarche/raisonnement dois-je suivre pour savoir ce qui va mal réagir à tel ou tel truc ?

**Trademark** · 10/03/2012, 13h43

Salut.

Concernant les choix de conception, je trouve que tu devrais utiliser un builder pour construire l'automate. La classe contiendrais les méthodes nécessaire pour construire l'automate et une méthode "build" qui renverrais new automaton(current_automaton);, l'objet "automaton" ne pourrait plus être modifié. La classe builder et automaton serait "friend".

Ensuite tu maintiens un état courant en donnée membre, ce qui signifie que ton automate ne peut pas être partagé entre plusieurs thread (et ce même si la table des transitions est énorme). Tu peux penser à "externaliser" l'état courant.

Les noms des méthodes sont probablement à revoir, quelle différence y a t'il entre NewTransitionForState et NewTransitionForCurrentState ? Difficile à dire avec le nom en tout cas...
En parlant de cette méthode, peut-être qu'il n'est pas utile de créer les transitions en dehors de l'automate, je verrais plutot quelque chose comme ça : void transition(State from, State to, Label l);.

Si tu veux rendre ton automate générique il faut au moins que tu proposes des label génériques eux aussi (et pas spécialement des std::string).

Ensuite par exemple ici : void Transition<T>::SetName(const std::string& name_) ; quelle est l'intérêt de mettre un "_" à la fin ? Aucun car c'est un prototype de fonction qui est sensé être lisible et niquel pour l'utilisateur.

Et finalement, dans ton design actuel, tu pourrais commencer à lire des états et puis parce que tu modifies les transitions en plein milieu te retrouver sur un état qui est, dans l'état courant de l'automate, à priori inaccessible.

**Kaamui** · 10/03/2012, 19h11

Tout d'abord, vraiment merci pour ta remarque constructive (et pleine de bon sens).

Envoyé par Trademark

Salut.

Concernant les choix de conception, je trouve que tu devrais utiliser un builder pour construire l'automate. La classe contiendrais les méthodes nécessaire pour construire l'automate et une méthode "build" qui renverrais new automaton(current_automaton);, l'objet "automaton" ne pourrait plus être modifié. La classe builder et automaton serait "friend".

J'avais prévu des handler mais ce que tu propose est encore mieux que cela

.

Envoyé par Trademark

Ensuite tu maintiens un état courant en donnée membre, ce qui signifie que ton automate ne peut pas être partagé entre plusieurs thread (et ce même si la table des transitions est énorme). Tu peux penser à "externaliser" l'état courant.

Très bonne idée, je ne vois aucune contestation

Envoyé par Trademark

Les noms des méthodes sont probablement à revoir, quelle différence y a t'il entre NewTransitionForState et NewTransitionForCurrentState ? Difficile à dire avec le nom en tout cas...

C'est vrai, mais en lisant les paramètres à la suite du nom, cela devien plus compréhensible, je vais réfléchir néanmoins à trouver quelque chose de plus parlant.

Envoyé par Trademark

En parlant de cette méthode, peut-être qu'il n'est pas utile de créer les transitions en dehors de l'automate, je verrais plutot quelque chose comme ça : void transition(State from, State to, Label l);.

désolé mais je ne saisi pas trop la différence(à part le label).

Envoyé par Trademark

Si tu veux rendre ton automate générique il faut au moins que tu proposes des label génériques eux aussi (et pas spécialement des std::string).

ça c'est une super idée par contre, c'est vrai que je trouvais cela assez limitant, mais ça ne m'a même pas traversé l'esprit pour autant, de le rendre générique.. Merci

Envoyé par Trademark

Ensuite par exemple ici : void Transition<T>::SetName(const std::string& name_) ; quelle est l'intérêt de mettre un "_" à la fin ? Aucun car c'est un prototype de fonction qui est sensé être lisible et niquel pour l'utilisateur.

Cela fait partie des erreurs de nomenclature que j'ai fait et dont 3DArchi m'avait déjà parlé. Je dois décider d'une autre "convention de nommage" pour mon projet, en effet.

Envoyé par Trademark

Et finalement, dans ton design actuel, tu pourrais commencer à lire des états et puis parce que tu modifies les transitions en plein milieu te retrouver sur un état qui est, dans l'état courant de l'automate, à priori inaccessible.

On est entièrement d'accord, je n'aime pas du tout cela, et je l'avais remarqué avant même d'implémenter, mais je ne sais pas trop comment m'y prendre, et sur ce point, j'ai vraiment besoin de tes lumières (ou de celles des autres membres émérite de ce forum), car je penses que cela tient de la gestion d'exception, et je ne suis pas trop à l'aise sur certains aspects, vis à vis de cela (je ne sais pas prévoir les exceptions qu'il va falloir que je gère, et je ne vois ce que je peux y faire une fois dans le catch, en gros).

Je ne te remercierais jamais assez pour ton intervention. J'ai vraiment le souci de rendre ce projet intéressant, et qu'il soit irréprochable, et simple à manier pour les autres. Et sans réaction des autres, je ne peux pas leur apporter ce dont ils ont (peut-être) besoin.

Merci Trademark ! +1 et + si je pouvais

**Trademark** · 10/03/2012, 19h30

De rien, de rien ^^

Tu n'auras pas besoin de gérer les exceptions si tu externalises tout ce dont on a parlé.

Je met en pièce jointe du code que j'avais écrit et qui reprend les conseils que je t'ai donné. Tu peux t'en inspirer librement. Il y a des "moins", on avait du utiliser une représentation matriciel, et ce n'est pas générique. Mais normalement c'est pensé pour être facilement géré. Il y a une erreur par contre pour le nom des classes (pas automata mais automaton).

Il gère les e-transition et il y a un algorithme de déterminisation. Il pourrait être intéressant de faire un algo de minimisation (qu'on peut lancer lors de l'appel à la méthode "build").

La documentation n'est pas bien faites non plus.

Enfin ça te donnera peut-être de l'inspiration.

**Kaamui** · 10/03/2012, 19h48

Envoyé par Trademark

De rien, de rien ^^

Tu n'auras pas besoin de gérer les exceptions si tu externalises tout ce dont on a parlé.

Je met en pièce jointe du code que j'avais écrit et qui reprend les conseils que je t'ai donné. Tu peux t'en inspirer librement. Il y a des "moins", on avait du utiliser une représentation matriciel, et ce n'est pas générique. Mais normalement c'est pensé pour être facilement géré. Il y a une erreur par contre pour le nom des classes (pas automata mais automaton).

Il gère les e-transition et il y a un algorithme de déterminisation. Il pourrait être intéressant de faire un algo de minimisation (qu'on peut lancer lors de l'appel à la méthode "build").

La documentation n'est pas bien faites non plus.

Enfin ça te donnera peut-être de l'inspiration.

Merci, c'est super pour les algo, et pour l'algo de minimisation ça doit être faisable, pour l'instant je vois pas trop comment faire, à part en essayant de copier-coller la méthode sur le papier, c'est à creuser... Mais je me demande si ce ne sera pas perturbant pour les utilisateurs, dans un contexte d'utilisation comme les jeux vidéos.

Par contre, e-transitions ? je connais pas je penses, ou sous un autre nom...

**Trademark** · 10/03/2012, 20h03

Je n'ai jamais développé des jeux vidéos mais il me semble que dans ce domaine, il n'utilise quasi pas de trucs tout fait pour des raisons d'optimisations. Enfin maintenant ça dépend surement de plein de facteurs et de ton implémentation.

En ce qui concerne les algo, je pense que le mieux c'est de minimiser lors de l'appel à la méthode 'build'. Grâce à ce pré-traitement, tu économises de la place. Mais ça peut être bien de laisser ce choix à l'utilisateur, avec un choix par défaut de le faire. Sinon tu peux laisser les algos hors de l'automate et prévoir des builder "wrappers" qui les encapsulent.. (build_minimize_automaton ou build_deterministic_automaton).

En ce qui concerne les e-transitions c'est pour les automates non déterministe, lorsque que tu es sur un état, s'il y a une e-transition alors tu peux te déplacer (et ce, sans lire de symbole) vers l'état pointé par cette e-transition. Du coup, au fur et à mesure que tu lis des symboles, tu peux "être" sur plusieurs états en même temps, c'est pas spécialement utile surtout qu'il faut gérer le fait que certaine e-transition peuvent générer des cycles et du coup, tu peux tourner en rond dans l'automate sans rien lire.

En bref, si c'est un automate déterministe, il n'y pas à parler de e-transition.

**Kaamui** · 10/03/2012, 20h40

Envoyé par Trademark

Je n'ai jamais développé des jeux vidéos mais il me semble que dans ce domaine, il n'utilise quasi pas de trucs tout fait pour des raisons d'optimisations. Enfin maintenant ça dépend surement de plein de facteurs et de ton implémentation.

En ce qui concerne les algo, je pense que le mieux c'est de minimiser lors de l'appel à la méthode 'build'. Grâce à ce pré-traitement, tu économises de la place. Mais ça peut être bien de laisser ce choix à l'utilisateur, avec un choix par défaut de le faire. Sinon tu peux laisser les algos hors de l'automate et prévoir des builder "wrappers" qui les encapsulent.. (build_minimize_automaton ou build_deterministic_automaton).

En ce qui concerne les e-transitions c'est pour les automates non déterministe, lorsque que tu es sur un état, s'il y a une e-transition alors tu peux te déplacer (et ce, sans lire de symbole) vers l'état pointé par cette e-transition. Du coup, au fur et à mesure que tu lis des symboles, tu peux "être" sur plusieurs états en même temps, c'est pas spécialement utile surtout qu'il faut gérer le fait que certaine e-transition peuvent générer des cycles et du coup, tu peux tourner en rond dans l'automate sans rien lire.

En bref, si c'est un automate déterministe, il n'y pas à parler de e-transition.

ah ok, des sigma-transitions xD je connaissais pas ce terme.

Non je souhaite empêcher l'utilisation d'automates non-déterministes.

Merci pour toutes ces précisions, je vais avoir un tas de truc à repenser maintenant, et ça pour mon plus grand bonheur

.

**Trademark** · 10/03/2012, 21h22

Ce n'est pas sigma, c'est epsilon et c'est une "sorte" de 'e' d'où e-transition (src : http://fr.wikipedia.org/wiki/%CE%95).

En tout cas bon courage pour tout ça

PS : tu peux regarder à une implémentation des automates dynamiques chez Boost, mais cette bibliothèque est encore en sandbox, donc c'est possible qu'il y ait des bugs. (Inspire toi en si tu as le courage de comprendre tout ça).

http://svn.boost.org/svn/boost/sandbox/automata/

Contrairement à ce qu'à dit Ekleog plus tôt qui proposait un lien vers des automates statiques (inchangeable après compilation) qui sont donc très optimisés au running-time.

**Kaamui** · 10/03/2012, 23h27

Envoyé par Trademark

Ce n'est pas sigma, c'est epsilon et c'est une "sorte" de 'e' d'où e-transition (src : http://fr.wikipedia.org/wiki/%CE%95).

En tout cas bon courage pour tout ça

PS : tu peux regarder à une implémentation des automates dynamiques chez Boost, mais cette bibliothèque est encore en sandbox, donc c'est possible qu'il y ait des bugs. (Inspire toi en si tu as le courage de comprendre tout ça).

http://svn.boost.org/svn/boost/sandbox/automata/

Contrairement à ce qu'à dit Ekleog plus tôt qui proposait un lien vers des automates statiques (inchangeable après compilation) qui sont donc très optimisés au running-time.

ah merde Epsilon c'est vrai xD

Pour boost, je sais mais je veux attendre d'avoir fait mes conneries pour regarder (et essayer de comprendre) ce qui a été fait chez les "gros balèzes"

**Kaamui** · 11/04/2012, 17h40

Envoyé par Trademark

Ensuite tu maintiens un état courant en donnée membre, ce qui signifie que ton automate ne peut pas être partagé entre plusieurs thread (et ce même si la table des transitions est énorme). Tu peux penser à "externaliser" l'état courant.

Bonjour, je réveille ce vieux topic, car je n'arrive pas à résoudre un problème, suite aux changements que j'ai effectué d'après tes huuuuuuumbles conseils

je tentes de rendre ma variable currentState externe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
#ifndef etc..
 
template <typename T, typename U>
extern State<T,U>* currentState;
 
class Automaton : 
//etc...
#endif //etc..

mais le compilateur me râle dessus :

template declaration of 'currentState'

et... c'est tout...je ne comprend pas trop, je penses que cela vient de la manipulation assez particulière que nécessite les "variables template externes", mais je ne vois pas comment faire, je me demande si j'ai vraiment compris ce que tu me conseillais... est-ce que quelqu'un a une idée ?

**Ekleog** · 11/04/2012, 19h50

Je ne pense pas que Trademark pensais à des variables globales (plutôt à une variable que l'utilisateur doit conserver et passer), mais, pour résoudre ton problème je te conseillerais de réfléchir au type que tu voudrais *vraiment* que currentState aie.

Une solution, en général, pour ce genre de problèmes, peut être l'encapsulation dans une struct, comme (non vérifié) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
template <typename T /*, ...*/> struct CurrentState {
   static State<T> var;
};

Mais je répèterai que ce n'est probablement pas ce à quoi Trademark pensait !

**Flob90** · 12/04/2012, 00h00

Je ne connais pas non plus toutes les subtilités des templates, mais je n'ai pas souvenir de "variable gloable template", où as-tu vu ce genre de code ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
template<typename T>
extern A<T>* currentState;
//Ou
template<typename T
A<T>* currentState;

**Kaamui** · 12/04/2012, 09h36

@Ekleog : maintenant que tu le dis, c'est vrai que ça ne doit pas être du tout ce qu'il proposait. Ta solution marche peut-être mais je trouve que ça fait trop "bidouille", mais je garde ça dans un coin de ma tête merci

@Flob90 : Donc tu penses que c'est une utilisation prohibée ?

Free Automatons with State and Transitions : soumission d'un projet

C++

Discussions similaires

Partager

Partager