Discussion :

[Antonin08]

Bonjour,

J'ai une classe

Code :

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

1
2
3
template<class Derived>
CBase {
};

2 classes dérivées

Code :

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

1
2
3
4
5
CDerivedA : public CBase <CDerivedA> {
};
 
CDerivedB : public CBase <CDerivedB> {
};

Est-ce qu'il es possible de créer un conteneur style map à partir de CBase pour y déposer CDerivedA et CDerivedB ??

[gbdivers]

Oui, avec boost::variant ou boost::any

[Emmanuel Deloget]

... ou non, sans boost.variant (ou boost.any).

CBase<X> est un type différente de CBase<Y>.

[dragonjoker59]

Je me disais aussi ... Tu peux effectivement faire dans CBase une std::map<MaClef, Derived>

[Antonin08]

... ou non, sans boost.variant (ou boost.any).

CBase<X> est un type différente de CBase<Y>.

Ce qui veut dire que je ne peux pas considérer CBase comme classe de base ?

Je me disais aussi ... Tu peux effectivement faire dans CBase une std::map<MaClef, Derived>

Pour précision :
J'utilise en ce moment Boost.Statechart. Et la classe de base est state_machine<MostDerived, InitialState>

Ce qui veut dire je ne veux/peux pas modifier le code de CBase

Mon intérêt ici est de pouvoir enregistrer dans un conteneur des objets de types différents. Mais je ne vois pas comment, aussi je cherche quelques pistes si vous avez des propositions...

Oui, avec boost::variant ou boost::any

J'ai déjà regardé un peu Boost.variant mais pour récupérer mon objet il faut que je connaisse le type et bien sur je ne le connais pas à l'exécution

Sans polymorphisme que devient-on ?

[gbdivers]

... ou non, sans boost.variant (ou boost.any).

Pas compris. Tu déconseilles l'utilisation de boost variant/any ici ?

J'ai déjà regardé un peu Boost.variant mais pour récupérer mon objet il faut que je connaisse le type et bien sur je ne le connais pas à l'exécution
Sans polymorphisme que devient-on ?

Tu veux faire quoi de tes objets ? Si tu veux appeler une fonction spécifique de chaque classe, tu peux utiliser le pattern visitor. Tu peux aussi appeler une fonction de la base. Sinon, tu peux explicitement récupérer le type de CBase (mais cela est souvent du à un problème de conception).

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
template<class Derived>
CBase {
   virtual void foo() const = 0;
};
 
CDerivedA : public CBase <CDerivedA> {
   virtual void foo() const { cout << "je suis A"; }
   void foo2() const { cout << "je suis encore A"; }
};
 
CDerivedB : public CBase <CDerivedB> {
   virtual void foo() const { cout << "je suis B"; }
   void foo2() const { cout << "je suis encore B"; }
};
 
struct output : public boost::static_visitor<> 
{ 
    void operator()(CBase <CDerivedA> const& d) const { d.foo2(); } 
    void operator()(CBase <CDerivedB> const& d) const { d.foo2(); } 
}; 
 
typedef boost::variant< CDerivedA, CDerivedB > cbase_t;
map<int, cbase_t> une_map;
une_map.insert(make_pair(0, CDerivedA()));
une_map.insert(make_pair(1, CDerivedB()));
 
// appelle de foo()
BOOST_FOREACH(const map<int, cbase_t>::value_type& une_paire, une_map)
{
   une_paire.second.foo();
}
 
// appelle de foo2()
BOOST_FOREACH(const map<int, cbase_t>::value_type& une_paire, une_map)
{
   boost::apply_visitor(output(), une_paire.second);
}
 
// Récupérer spécifiquement le type
CDerivedA value = boost::get<CDerivedA>(une_map[0]);

Le fait que les 2 classes dérivent de la même classe template de base (donc de 2 classes différentes après l'instanciation du template) n'a aucune utilité ici. Donc même pas besoin d'avoir des fonctions virtuelles.

J'utilise en ce moment Boost.Statechart. Et la classe de base est state_machine<MostDerived, InitialState>
Ce qui veut dire je ne veux/peux pas modifier le code de CBase

Tu peux créer une classe CBase qui est lié à state_machine<MostDerived, InitialState> par composition. As tu réellement besoin de l'héritage et du CRTP ?

[Antonin08]

Tu veux faire quoi de tes objets ? Si tu veux appeler une fonction spécifique de chaque classe, tu peux utiliser le pattern visitor. Tu peux aussi appeler une fonction de la base. Sinon, tu peux explicitement récupérer le type de CBase (mais cela est souvent du à un problème de conception).

Effectivement j'appelle la fonction process_event(const event_base & evt) qui aura pour effet de changer l'état de l'objet suivant l'évènement passé. C'est pour cela que je dois connaître le type de l'objet auquel je m'adresse. (clair !!! pas sur). Je ne peux adresser un évènement qui n'est pas reconnu par l'objet.

Tu peux créer une classe CBase qui est lié à state_machine<MostDerived, InitialState> par composition. As tu réellement besoin de l'héritage et du CRTP ?

L'héritage oui pour avoir plusieurs objets distincts. Le CRTP est implémenté par la librairie. (pas le choix a priori)

Par contre la composition peut être intéressante. Est-ce que tu pourrais développer un peu ta pensée ?

Pour revenir à ton code, ce que je disais c'est que je ne connais pas à priori le type de l'objet qui je vais utiliser, je m'adresse à lui au travers d'un numéro (clé map par exempleà ou une chaîne de caractère "CDerivedX".

[gbdivers]

J'ai du mal à comprendre :
- Tu as bien plusieurs machines à états, chacune de ces machines ayant sa propre liste d'états et de transitions ?
- Tu as bien plusieurs types de machines à états, chacune de ces machines ayant un comportement spécifique ? Dans ce cas, quel comportement tu redéfinis ?

De plus, les events ne sont pas spécifique d'une machine à états en particulier. Donc tu peux appeler process_event sur toutes tes machines à états, si tu ne définis pas une transition basée sur l'event, tu n'auras pas de changement d'états (ce qui revient à dire que tu veux faire sans problème un foreach)

[Emmanuel Deloget]

Ce qui veut dire que je ne peux pas considérer CBase comme classe de base ?

CBase n'est PAS ta classe de base. CBase n'existe pas, seule CBase<T> existe. Et dans ton cas, c'est CBase<X>, ou CBase<Y> selon le type considéré.

Sans polymorphisme que devient-on ?

Tiens, on se met à parler philosophie maintenant ?

Pas compris. Tu déconseilles l'utilisation de boost variant/any ici ?

Non, je disais juste que sans ça, ça ne pouvait pas marcher. Un pendant à ta réponse, en quelques sortes

Ceci dit, si on veut parler design, alors là oui : partout ou un type variant est utilisé, un bébé lapin meurt. Il faut donc éviter au maximum de les utiliser

Vu le système proposé, ça ressemble fort à un gros problème de conception.

[Antonin08]

J'ai du mal à comprendre :
- Tu as bien plusieurs machines à états, chacune de ces machines ayant sa propre liste d'états et de transitions ?
- Tu as bien plusieurs types de machines à états, chacune de ces machines ayant un comportement spécifique ? Dans ce cas, quel comportement tu redéfinis ?

Je ne redéfinis aucun comportement.

De plus, les events ne sont pas spécifique d'une machine à états en particulier. Donc tu peux appeler process_event sur toutes tes machines à états, si tu ne définis pas une transition basée sur l'event, tu n'auras pas de changement d'états (ce qui revient à dire que tu veux faire sans problème un foreach)

Effectivement si je n'ai pas de transition basée sur l'event il n'y aura pas de changement d'état. Un foreach pourrait être indiqué mais je ne souhaite pas boucler sur des machines à états qui n'ont pas l'event défini, histoire d'optimisation ; en effet je suis censé traiter un très très grand nombre d'évènement.

CBase n'est PAS ta classe de base. CBase n'existe pas, seule CBase<T> existe. Et dans ton cas, c'est CBase<X>, ou CBase<Y> selon le type considéré.

En fait je n'avais pas totalement réalisé que CBase<X> et CBase<Y> sont des types différents. C'est la première fois que j'utilise le CRTP

Vu le système proposé, ça ressemble fort à un gros problème de conception.

Le système a été réfléchi et c'est de façon volontaire que les méthodes virtuelles et les mécanismes "traditionnels" du polymorphisme n'ont pas été implémenté. C'est une recherche de performance, qui je crois, a amené les concepteurs de cette librairie vers ce type de programmation

Une idée vient de me passer par la tête.

Et si je définis une classe tout simple MBase

Code :

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

1
2
3
 
class MBase {
};

Et que j'utilise l'héritage multiple

Code :

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

1
2
3
 
class CDerivedA : public CBase<CDerivedA> ,  MBase {
}

De cette façon je crée un conteneur avec MBase qui stocke bien mes objets CDerivedA, CDerivedB, ...
Et à lorsque je récupère l'objet je peux appeler directement process_event

[gbdivers]

Je ne redéfinis aucun comportement.

Donc tu n'as pas besoin de dériver la classe state_machine (et de créer plusieurs classes dérivées). Du coup, tu peux mettre toutes tes state_machine dans un même conteneur.

Effectivement si je n'ai pas de transition basée sur l'event il n'y aura pas de changement d'état. Un foreach pourrait être indiqué mais je ne souhaite pas boucler sur des machines à états qui n'ont pas l'event défini, histoire d'optimisation ; en effet je suis censé traiter un très très grand nombre d'évènement.

Soit ce sont des events "génériques" (c'est à dire non lié spécifiquement à une state_machine particulière) et dans ce cas, c'est le boulot de la state_machine de testé si l'event est pris en compte ou pas.
Soit ce sont des events "spécifiques" (c'est à dire que tu as créé pour chaque state_machine une liste d'event) et dans ce cas, un simple mapping suffira pour récupérer la state_machine correspondante à un event.

Mais l'argument des performances me semble limite :
- le dispatching (retrouver la state_machine qui correspond à un event en particulier) sera probablement presque aussi coûteux que les tests (si tu utilises un vector<state_machine> et que l'event te retourne un index dans le vecteur)
- la plupart de tes events ne déclencheront probablement pas de transition. Ce qui revient à dire que la plupart des events consomment du temps pour rien. Mais c'est le boulot de la machine à états d'être efficace dans le traitement des events. En voulant "pré-traiter" les events, tu piques un peu de la responsabilité de la machine à états.
- jamais, jamais, jamais et jamais faire de l'optimsation sans avoir vérifier que c'est nécessaire ! Écris ton code de base en laissant les machines à états faire leurs boulots. Et si tu vois qu'il y a une perte de performance quelque part, tu améliores après (et comme tu as bien réfléchi à ta conception et que tu respectes les principes de la POO, l'évolution de ton code est très simple).

Bref, fait un simple for_each sur chaque state_machine pour appeler process_event.

En fait je n'avais pas totalement réalisé que CBase<X> et CBase<Y> sont des types différents. C'est la première fois que j'utilise le CRTP

C'est pas un problème de compréhension du CRTP mais des templates : 2 instanciations différentes d'une même classe template avec de arguments différents sont bien 2 classes différentes.

Le système a été réfléchi et c'est de façon volontaire que les méthodes virtuelles et les mécanismes "traditionnels" du polymorphisme n'ont pas été implémenté. C'est une recherche de performance, qui je crois, a amené les concepteurs de cette librairie vers ce type de programmation

En fait, Emmanuel parlait de ta conception et pas celle de boost
Boost est une bibliothèque suffisamment critique pour qu'elle soit validé en long, en large et en travers (et par des experts reconnus du C++) et qu'elle soit optimisé pour les performances (en autre). Mais la contrepartie est qu'elle est parfois difficile à utiliser pour les débutants (ou plutôt qu'elle est mal utilisée par les débutants).

Une idée vient de me passer par la tête.
Et si je définis une classe tout simple MBase

Code :

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

1
2
3
 
class MBase {
};

Et que j'utilise l'héritage multiple

Code :

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

1
2
3
 
class CDerivedA : public CBase<CDerivedA> ,  MBase {
}

De cette façon je crée un conteneur avec MBase qui stocke bien mes objets CDerivedA, CDerivedB, ...
Et à lorsque je récupère l'objet je peux appeler directement process_event

Hum, c'est ce qui est proposé dans la documentation pour les events et les transitions... donc oui, c'est la méthode recommandée (mais en mettant en premier la classe parent puis la classe boost, je sais pas si ça change quelque chose ici).


Donc pour résumé :
- tu fais un vecteur/list de state_machine
- tu créés tes transitions/états
- pour chaque event, tu appelles process_event
- tu vérifies les performances
- tu optimises (ou pas)


Question subsidiaire : pourquoi tu as plusieurs machines à états ? et combien en as tu ? comment gères tu la création de tes graphs d'états ?

[Antonin08]

Donc tu n'as pas besoin de dériver la classe state_machine (et de créer plusieurs classes dérivées). Du coup, tu peux mettre toutes tes state_machine dans un même conteneur.

Pas compris ?
state_machine est une classe template je suis donc obligé de créer mes classes dérivées...

Soit ce sont des events "génériques" (c'est à dire non lié spécifiquement à une state_machine particulière) et dans ce cas, c'est le boulot de la state_machine de testé si l'event est pris en compte ou pas.
Soit ce sont des events "spécifiques" (c'est à dire que tu as créé pour chaque state_machine une liste d'event) et dans ce cas, un simple mapping suffira pour récupérer la state_machine correspondante à un event.

Ce sont des events "spécifiques", oui.
Par mapping tu entends tester l'existence de l'event pour chaque state machine ?

Mais l'argument des performances me semble limite :
- le dispatching (retrouver la state_machine qui correspond à un event en particulier) sera probablement presque aussi coûteux que les tests (si tu utilises un vector<state_machine> et que l'event te retourne un index dans le vecteur)
- la plupart de tes events ne déclencheront probablement pas de transition. Ce qui revient à dire que la plupart des events consomment du temps pour rien. Mais c'est le boulot de la machine à états d'être efficace dans le traitement des events. En voulant "pré-traiter" les events, tu piques un peu de la responsabilité de la machine à états.
- jamais, jamais, jamais et jamais faire de l'optimsation sans avoir vérifier que c'est nécessaire ! Écris ton code de base en laissant les machines à états faire leurs boulots. Et si tu vois qu'il y a une perte de performance quelque part, tu améliores après (et comme tu as bien réfléchi à ta conception et que tu respectes les principes de la POO, l'évolution de ton code est très simple).

Je suis d'accord après quelques tests le traitement d'un évènement-transition n'est quasiment pas consommant (1million d'event -> 70ns) avec une machine à 4 états.

Bref, fait un simple for_each sur chaque state_machine pour appeler process_event.

Oui si je n'avais pas plusieurs instances du même state_machine. Car dans ce cas là un event s'adresserait à toutes les instances d'un même state machine, ce qui n'est pas forcément voulu

C'est pas un problème de compréhension du CRTP mais des templates : 2 instanciations différentes d'une même classe template avec de arguments différents sont bien 2 classes différentes.

Oui c'est très possible

Hum, c'est ce qui est proposé dans la documentation pour les events et les transitions... donc oui, c'est la méthode recommandée (mais en mettant en premier la classe parent puis la classe boost, je sais pas si ça change quelque chose ici).

Je veux bien que tu me dises où tu as lu cette information dans la documentation. Je suis sûrement passé à coté

Question subsidiaire : pourquoi tu as plusieurs machines à états ? et combien en as tu ?

Pourquoi je ne saurais vraiment le dire peut être pour simplifier l'écriture, gérer plusieurs points d'entrée, créer plusieurs instances, séparer les fonctionnalités...
Il n'y a pas de limite mais disons entre 10 et 50 en moyenne.

comment gères tu la création de tes graphs d'états ?

Kesako ?