Closed kuuse closed 4 years ago
Example target_state() implementation:
--- fsmlite.h 2020-06-05 13:22:31.983294087 +0200
+++ fsmlite-target.h 2020-06-05 16:55:37.060732650 +0200
@@ -195,7 +195,7 @@
*
* @param init_state the FSM's initial state
*/
- fsm(state_type init_state = state_type()) : m_state(init_state) {}
+ fsm(state_type init_state = state_type()) : m_state(init_state), m_target(init_state) {}
/**
* Process an event.
@@ -220,9 +220,10 @@
}
/**
- * Return the state machine's current state.
+ * Return the state machine's current and target states.
*/
state_type current_state() const { return m_state; }
+ state_type target_state() const { return m_target; }
protected:
/**
@@ -407,6 +408,7 @@
template<class Event, class T, class... Types>
struct handle_event<Event, detail::list<T, Types...>> {
static State execute(Derived& self, const Event& event, State state) {
+ self.m_target = T::target_value();
return state == T::start_value() && T::check_guard(self, event) ?
T::process_event(self, event), T::target_value() :
handle_event<Event, detail::list<Types...>>::execute(self, event, state);
@@ -422,6 +424,7 @@
private:
state_type m_state;
+ state_type m_target;
private:
#if !defined(NDEBUG) && (!__GNUC__ || __EXCEPTIONS)
Basically, target_state
only makes sense while a transition is executing, so I don't think a member function makes much sense here. If the behavior of the action actually depends on the target state, IMHO it is clearer to provide separate action functions in the first place.
Hi,
Maybe I am missing something fundamental here. Besides
current_state()
, wouldn't it be useful to havetarget_state()
?An example: I am creating a SIP packet analyzer. At the moment I just want to save the timestamp of the incoming packet. See the
transition_table
below. As seen in the table, the same Action,SaveTimestamp()
, could be used for all packets iftarget_state()
could be accessed from withinSaveTimestamp()
.Best Regards, Johan