Boost logo

Boost Users :

Subject: Re: [Boost-users] [msm] Why does it take so many bytes to represent a state machine?
From: 谢任中 (joshchia_at_[hidden])
Date: 2012-11-13 18:37:25


If it can be shrunk to the size of an int for the stripped-down use case,
for storing the state ID, which is what's really needed in principle, it
would be nice, but I think a 20-byte overhead is not a show-stopper for me
for now.

On Tue, Nov 13, 2012 at 4:31 PM, Christophe Henry <
christophe.j.henry_at_[hidden]> wrote:

> **
> >Thanks for the quick response and thanks for making this handy library.
> >
> >I turned off message queueing (typedef int no_message_queue) and I'm down
> to 20 bytes, much better, though still
> >with some unaccounted bytes. I'm looking for a better way.
> >
> >I don't use any attributes, except for event attributes, or submachines.
> I also don't care about event/state history.
>
> Event attributes have no memory cost on your state machine. History costs
> the same as the id (an int per region).
>
> >This means the only state-related info is the state ID. What about just
> reading and storing the state ID, and using the stored ID
> >to restore the state next time I need to process an event? I know how to
> get state ID (current_state()), but how do I set state from ID?
>
> You cannot set the state, MSM handles the lifecycle of its states.
>
> >
> >Josh
>
> MSM just stores the id of the current state(s) in order to call
> on_entry/on_exit or for bookkeeping. MSM does not recreate the active
> states after each transition but insteads keeps them alive for performance
> reasons. This also allows you to store data in states (you need this quite
> often).
> I don't know how many bytes still are needed for your text archive, you
> should ask this to Robert Ramey.
>
> Christophe
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net