Очевидно, что boost содержит две отдельные библиотеки для состояний машин: Statechart и Meta State Machine (МСМ). В тегах есть очень похожие описания:
Знаете ли вы, какие ключевые различия и каковы соображения при выборе между ними?
Как представляется, существует большой интерес, пожалуйста, позвольте мне дать мое (явно предвзятое) мнение, которое следует поэтому взять с солью:
Вы можете сделать лучшее мнение, просмотрев комментарии, опубликованные во время обзора МСМ. Этот вопрос обсуждался в списке разработчиков.
Как уже упоминал Кристоф, одним из ключевых различий между двумя библиотеками является производительность во время выполнения. Хотя MSM, вероятно, предлагает лучшее, что вы можете получить здесь, Statechart сознательно торгует памятью и процессорными циклами в целях повышения масштабируемости.
С Boost.Statechart вы можете распространять макет (то есть состояния, переходы) вашего конечного автомата на несколько единиц перевода (файлы cpp) способами, которые вы не можете с помощью MSM. Это позволяет сделать реализацию больших FSM более удобной и более быстрой компиляции, чем с MSM.
Независимо от того, будут ли накладные расходы на производительность Statechart по сравнению с MSM действительно значимыми для вашего приложения, часто довольно легко ответить, когда вы задаете себе вопрос, сколько событий ваше приложение будет обрабатывать в секунду.
Если предположить умеренно сложный FSM, реализованный с помощью Boost.Statechart, вот несколько номеров шаров:
Что касается загрузки ЦП, если количество событий для обработки намного ниже этих чисел, то накладные расходы Boost.Statechart по сравнению с MSM почти наверняка не будут заметны. Если число намного выше, вам определенно лучше работать с МСМ.
Более подробную информацию о компрометации производительности/масштабируемости можно найти здесь: http://www.boost.org/doc/libs/1_45_0/libs/statechart/doc/performance.html
При кодировании моей собственной реализации PPP я использовал Statechart по трем причинам: 1) Statechart проще и имеет более четкую документацию; 2) Мне очень не нравится UML:)
Boost docs говорят, что MSM по крайней мере в 20 раз быстрее, но компилирует довольно медленно для большого FSM.
Некоторое время назад я начал с Statechart и перешел в MSM, потому что его проще было использовать в сочетании с asio из одного потока. Мне не удалось сшить Statechart и его многопоточные возможности с моим использованием asio - это, скорее всего, какое-то новизна, непонимание Statechart с моей стороны. Я обнаружил, что MSM проще в использовании, поскольку он не учитывает многопоточность.
В ответ на Тим поздний вход в дискуссию (в котором также рассматривается один из самых ранних комментариев Лев).
Как один из тех, кто утверждал о выходе из деструкторов в statechart (аргумент, основанный на реальном использовании, о взаимодействии с реальным миром, т.е. I/O), назад, когда он был отправлен в Boost, я согласен, что могут быть проблемы в постановке логики выхода в деструкторах. Дэвид Авраамс неудивительно сделал убедительные аргументы в отношении безопасности исключений. По этим причинам Statechart не требует, чтобы вы вводили логику в деструкторы, но это позволяет вам - с обычным советом.
Логика, которая должна выполняться только как часть перехода из состояния (а не уничтожения объекта statechart в целом), может (и должна быть, если есть необходимость очистки ресурсов) быть разделена на отдельный выход() действие.
Для "тонкого" состояния без активного состояния (ресурсов), только для действий входа/выхода для выполнения, вы можете выполнять эти действия в ctor и d'tor и убедиться, что конструктор и деструктор не выбрасывают. Для них нет причин - нет государства для выполнения RAII - нет никакого зла в том, что обработка ошибок в этих местах поднимает соответствующие события. Вам все равно придется учитывать, хотите ли вы выполнять действия выхода, которые изменяют внешнее состояние для запуска при уничтожении конечных автоматов, хотя... и помещают их в действие exit, если вы не хотите, чтобы они возникали в этом случае...
Активация моделей Statechart как создание объекта, поэтому, если у вашего конструктора есть реальная работа/активация/создание экземпляра, и если он способен к сбою, так что состояние не может быть введено. Statechart поддерживает это, предоставляя вам возможность сопоставлять исключение из события. Это обрабатывается таким образом, что работает над иерархией состояний, которая ищет внешнее состояние, которое обрабатывает событие исключения, аналогично тому, как стек разматывался для модели вызова на основе стека вызовов.
Все это хорошо документировано - я предлагаю вам ознакомиться с документами и попробовать. Я предлагаю вам использовать деструкторы для очистки "ресурсов программного обеспечения" и действий выхода для выполнения "действий выхода из реального мира".
Следует отметить, что распространение исключений является проблемой во всех средах, управляемых событиями, а не только в виде диаграмм состояния. Лучше всего рассуждать и включать ошибки/ошибки в свой проект statechart, и только тогда, когда вы не можете справиться с ними, иначе примените к отображению исключений. По крайней мере, это работает для меня - ymmmv....