Machine d’états transitions c. État du Meta Boost

Question

Apparemment boost contient deux bibliothèques distinctes pour les machines d'état: Statechart et Méta-État de la Machine (MSM). Le slogan de donner un très semblables descriptions:

• Coup de pouce.Etats - Arbitrairement complexes des machines à états finis peut être mis en œuvre facilement lisible et maintenable code C++.
• Méta-État de la Machine - Une très haute performance de la bibliothèque expressives UML2 des machines à états finis.

Savez-vous quelles sont les principales différences et quelles sont les considérations à choisir entre les deux?

Answer 1

Comme il semble y avoir beaucoup d'intérêt, merci de me permettre de donner mon (évidemment biaisée) de l'opinion, qui doivent donc être pris avec un grain de sel:

• Le MSM est beaucoup plus rapide
• MSM nécessite pas de RTTI ou quoi que ce soit virtuel
• MSM a une plus complète UML2 de soutien (par exemple des transitions UML-être orthogonale régions)
• MSM offre un langage descriptif (en fait plusieurs). Par exemple, à l'aide de la eUML front-end, une transition peut être décrit comme Source + Événement [Garde] / Action == Cible
• MSM fera de votre compilateur souffrir pour le plus grand état des machines, de sorte que vous aurez besoin d'un assez récents compilateur g++ >= 4.x, CR >= 9)

Vous pouvez vous faire une meilleure opinion par la recherche de commentaires affichés lors de l'examen de MSM. Ce sujet a été beaucoup discuté sur la liste des développeurs.

Answer 2

Comme Christophe l'a déjà mentionné, l'une des principales différences entre les deux bibliothèques est les performances d'exécution. Alors que le MSM offre probablement le meilleur que vous pouvez obtenir ici, Statechart consciemment des métiers de la mémoire et de cycles de processeur vers une meilleure évolutivité.

Avec Boost.Statechart, vous pouvez répandre la mise en page (c'est à dire les états, les transitions) de votre machine d'état sur plusieurs unités de traduction (fichiers cpp) dans les moyens que vous ne pouvez pas avec le MSM. Cela permet de faire de la mise en œuvre de grands Smqs plus facile à gérer et beaucoup plus rapide de la compilation qu'avec le MSM.

Si oui ou non la charge des Etats par rapport aux HSH sera réellement significatif pour votre application est souvent assez facile de répondre quand vous vous demandez comment de nombreux événements de votre application aura à traiter par seconde.

En supposant que modérément complexe MPF mis en œuvre avec Boost.Statechart, voici quelques ballpark numéros:

• La plupart des PC actuels pourrez facilement faire face avec >100'000 événements par seconde
• Même très limité en ressources matérielles seront en mesure de traiter quelques centaines d'événements par seconde.

Concernant la charge CPU, si le nombre d'événements à traiter est beaucoup plus faible que ces numéros, coup de pouce.Etats généraux par rapport aux HSH aurez presque certainement pas être perceptible. Si le nombre est beaucoup plus élevé, vous êtes certainement mieux avec le MSM.

Des informations plus détaillées sur la performance/évolutivité des compromis peuvent être trouvés ici: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html

Answer 3

Alors que ma propre implémentation PPP de codage, j’ai utilisé Statechart pour trois raisons : 1) Statechart est plus simple et a une documentation plus claire ; 2) je n’aime vraiment pas UML  :)

Coup de pouce docs dire MSM est au moins 20 fois plus rapide, mais compile assez lent pour grand FSM.

Answer 4

Il y a quelque temps j’ai commencé avec transitions et s’installe à MSM parce qu’il était plus facile à utiliser en conjonction avec asio à partir d’un thread unique. Je n'ai pas réussi à maille Statechart et ses capacités de multithreading avec mon utilisation d’asio - c’était probablement une sorte d’incompréhension newbie de transitions de ma part. J’ai trouvé que le MSM a été plus facile à utiliser car il ne traitait pas multithreading.