Boost Statechart vs Meta État de la Machine

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?

  • Hehe, un autre cas de beaucoup d'intérêt, mais personne ne connaît la réponse... 🙂
  • 😀 Cette question est le summum de mon expérience! Obtenir des réponses à partir à la fois des développeurs... peut-il faire mieux?! Un grand merci à Christophe et Andreas.
  • Excellente question, et vous avez réussi à obtenir les réponses des deux concurrentes des développeurs !
  • Statechart fait de vous mettre la fonctionnalité des constructeurs et des destructeurs. C'est un anti-modèle, en particulier avec les destructeurs.
  • Dans Statechart, les actions de sortie peut être mis dans un autre exit() gestionnaire appelé avant la destruction. Je pense que cette disposition atténue le principal problème avec l'anti-modèle, que Lev mentionne.
InformationsquelleAutor FireAphis | 2010-11-25
  1. 112

    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:

    • 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, VC >= 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.

    • Je vous remercie beaucoup. C'est un régal d'entendre l'avis du développeur lui-même! Maintenant, nous avons seulement besoin de la réponse de Andreas Huber 🙂
    • Mineur nit-pick: En mode de diffusion, l'utilisation de C++ RTTI (dynamic_cast, typeid) est strictement facultatif avec Boost.Statechart.
    InformationsquelleAutor Christophe Henry
  2. 109

    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 disposition (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 de ressources limitées, le matériel sera 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.

    Plus en profondeur de l'information 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

    • Salut Andreas, sur l'étalement de la mise en page, il y a eu quelques améliorations. Vous pouvez maintenant compiler sur les machines partielles sur les différents cœurs. Il n'est pas parfait mais c'est une amélioration notable. Voir svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/...
    InformationsquelleAutor Andreas Huber
  3. 11

    Lors de l'encodage de ma propre implémentation PPP j'ai utilisé Statechart pour trois raisons:
    1) Statechart est plus simple et a plus claire de la documentation;
    2) je n'aime vraiment pas UML 🙂

    Stimuler les docs disent que le MSM est au moins 20 fois plus rapide, mais compile assez lent pour les grandes FSM.

    • Que je suis d'accord que beaucoup d'UML est les empereurs de nouveaux vêtements, de l'état, les graphiques sont la seule chose qui a réellement de la valeur en UML.
    • Certainement, mais j'ai appris diagrammes d'états-transitions depuis les mathématiques discrètes, pas de génie logiciel. Cela laisse une marque 🙂
    InformationsquelleAutor blaze
  4. 4

    Il y a quelques temps, j'ai commencé le Statechart et a déménagé à MSM car c'est plus facile à utiliser en conjonction avec asio à partir d'un seul fil. Je n'ai pas réussi à maille Statechart et de ses capacités de multithreading avec mon utilisation de l'asio, c'était probablement une sorte de newbie l'incompréhension de Statechart de ma part. J'ai trouvé que le MSM a été plus facile à utiliser qu'il n'a pas d'adresse multithreading.

    • La plupart des etats ne sont pas d'adresse filetage soit. En ce qui concerne le multithreading, vous devriez être en mesure d'utiliser boost::statechart::state_machine juste comme le MSM homologue. boost::statechart::asynchronous_state_machine et types associés sont strictement de la partie optionnelle du statechart de la bibliothèque.
    InformationsquelleAutor Gordon M. Smith
  5. 2

    En réponse à Tim entrée tardive à la discussion (qui traite aussi l'un des premiers commentaires de la Lev).

    Comme l'un de ceux qui ont plaidé pour la sortie de la séparation de destructeurs dans statechart (argument basé sur un vrai cas d'utilisation, sur les interactions avec le monde réel, c'est à dire I/O) chemin du retour quand il a été soumis à Stimuler la je suis d'accord il peut y avoir des problèmes en mettant à la sortie de la logique dans les destructeurs. David Abrahams, sans surprise, fait des arguments convaincants au sujet de l'exception de sécurité ainsi. Pour ces raisons, les Etats ne vous obligent pas à mettre de la logique dans les destructeurs - mais il vous permet d' - avec les conseils habituels.

    Logique qui ne doit jamais s'exécuter dans le cadre d'une transition d'un état (pas de destruction de la statechart objet comme un tout) peut (et doit, si il y a aussi des ressources de nettoyage à faire) être séparés dans un exit() de l'action.

    Pour une "mince" état sans état actif (ressources), juste à l'entrée/sortie d'actions à effectuer, vous pouvez effectuer ces actions dans ctor et d'tor et assurez-vous que le constructeur et le destructeur de ne pas le jeter. Il n'y a aucune raison pour eux d' - il n'est pas en état d'exécuter RAII sur il n'y a pas de mal en ayant la gestion d'erreur dans ces lieux de soulever des événements. Vous pouvez encore avoir besoin de vous demander si vous voulez quitter actions qui modifient extérieure de l'état pour l'exécuter sur la machine d'état de la destruction mais... et les mettre dans la sortie de action si vous ne voulez pas de se produire dans ce cas...

    Statechart modèles d'activation, comme l'instanciation d'un objet, donc si votre constructeur a un réel travail/activation/instanciation à faire et si il est capable d'échouer, tels que l'état ne peut pas être entré Statechart soutient qu'en vous donnant la possibilité de mapper une exception pour un événement. C'est géré d'une manière qui fonctionne jusqu'à l'état de la hiérarchie de la recherche d'une enveloppe extérieure de l'état qui gère l'événement d'exception, analogue à la façon de la pile aurait déroulé pour une pile d'appel basé modèle d'invocation.

    Cela est bien documenté - je vous suggère de lire les docs et de l'essayer. Je vous suggère d'utiliser destructeurs pour nettoyer logiciel "ressources" et les actions de sortie à effectuer "dans le monde réel les actions de sortie".

    Il est intéressant de noter de noter que la propagation d'exception est un peu le problème dans tous les cas environnements, et pas seulement les diagrammes d'états. Il est préférable de raisonner sur et comprennent les fautes et les erreurs dans votre statechart de conception, et si et seulement si vous ne pouvez pas les traiter d'une autre manière recourir à l'exception de la cartographie. Au moins qui fonctionne pour moi - ymmmv....

    • Merci, je vois que tous mes préoccupations sont suffisamment pris en compte dans la "gestion des exceptions" une partie de la Boost::statechart tutoriel. Dans ce cas, je pense que Lev s (trompeuse) commentaire peut être réglée simplement en pointant des "deux étapes de la sortie de" section de ce tutoriel. Je voudrais envisager de supprimer ma réponse, sauf que votre propre réponse ajoute de précieuses informations à ce sujet.
    InformationsquelleAutor da77a