Hey there! As someone who’s worked with Boost MSM’s eUML frontend quite a bit, I totally get where you’re coming from—it’s an incredibly powerful tool, but wrapping your head around data flow between the state machine and external systems can feel tricky at first. Both of your proposed approaches are valid, so let’s dive into concrete implementations for each, plus some best practices to keep things clean and maintainable.

Approach 1: Using State Machine Attributes (Recommended) #

This is the cleanest, most encapsulated way to handle data sharing, since it ties state machine data directly to the FSM instance instead of relying on messy globals. Here’s how to make it work step-by-step:

Step 1: Define your attribute structure #

First, create a struct to hold all the data your state machine needs to share with the outside world:

#include <boost/msm/back/state_machine.hpp>
#include <boost/msm/front/euml/euml.hpp>
#include <string>

using namespace boost::msm::front::euml;

// Struct to hold all shared state machine data
struct FsmAttributes {
    int sensor_reading = 0;
    std::string current_status = "initialized";
    // Add any other fields you need to share
};

Step 2: Attach attributes to your eUML state machine #

When defining your state machine, use the attributes_ helper to link your attribute struct to the FSM:

// Example states and events (adjust to your use case)
BOOST_MSM_EUML_STATE((), IdleState)
BOOST_MSM_EUML_STATE((), ActiveState)
BOOST_MSM_EUML_EVENT(StartEvent)
BOOST_MSM_EUML_EVENT(UpdateSensorEvent)

// Transition table with actions that modify attributes
BOOST_MSM_EUML_TRANSITION_TABLE((
    IdleState + StartEvent == ActiveState / [](fsm& f) {
        // Update attributes from within a state transition action
        f.attr().current_status = "active";
    },
    ActiveState + UpdateSensorEvent == ActiveState / [](fsm& f) {
        // Simulate updating a sensor value from the state machine
        f.attr().sensor_reading += 10;
    }
), transition_table)

// Declare the state machine with attached attributes
BOOST_MSM_EUML_DECLARE_STATE_MACHINE((
    transition_table,  // Transition logic
    init_ << IdleState, // Initial state
    attributes_ << FsmAttributes // Link your attribute struct
), MyStateMachine)

// Type alias for the backend state machine implementation
using MyFsmBackend = boost::msm::back::state_machine<MyStateMachine>;

Step 3: Access attributes from external code #

Once you have an instance of your FSM, you can directly read or modify attributes via the attr() method:

int main() {
    MyFsmBackend fsm;
    fsm.start();

    // Trigger events to modify state machine data
    fsm.process_event(StartEvent());
    fsm.process_event(UpdateSensorEvent());

    // Read attributes from outside the state machine
    std::cout << "Current status: " << fsm.attr().current_status << std::endl;
    std::cout << "Sensor reading: " << fsm.attr().sensor_reading << std::endl;

    // You can also modify attributes externally (use caution with thread safety!)
    fsm.attr().sensor_reading = 50;
    return 0;
}

Note: If your state machine runs in a separate thread, add mutex locks around attribute access to avoid race conditions.

Approach 2: Using Global Variables (Not Recommended) #

While this works, it’s generally a bad practice because it introduces tight coupling, makes testing harder, and can cause thread-safety issues. That said, if you need a quick workaround for a simple use case, here’s how it would look:

// Global variable for shared data (avoid this in production!)
int global_sensor_data = 0;

// Transition table that updates the global variable
BOOST_MSM_EUML_TRANSITION_TABLE((
    ActiveState + UpdateSensorEvent == ActiveState / []() {
        // Modify the global variable from a state action
        global_sensor_data += 10;
    }
), transition_table)

// External code reads the global variable directly
int main() {
    MyFsmBackend fsm;
    fsm.start();
    fsm.process_event(StartEvent());
    fsm.process_event(UpdateSensorEvent());

    std::cout << "Global sensor data: " << global_sensor_data << std::endl;
    return 0;
}

Seriously—stick with state machine attributes unless you have no other choice. Globals will come back to haunt you as your project grows.

Bonus: Loose Coupling with Callbacks #

If you want even more separation between your state machine and external systems, consider using callback functions or an observer pattern. For example, you could add a std::function to your attribute struct, then call it from state actions to notify external code of changes. This keeps your FSM decoupled from specific external systems and makes testing easier.

内容的提问来源于stack exchange，提问作者Max Li