|
Boost : |
Subject: Re: [boost] [msm]how to distinguish region ids?
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-06-21 17:23:23
Hi, Christohe
Thanks for quick reply.
On Tue, 21 Jun 2011 21:09:20 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:
> > Hello,
> >
> > On Boost.Msm 1.46.1,
> > When I use explicit entries and entry pseudo states, I have to provide a
> > template argument "region id".
> > http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e930
> >
> > But I couldn't find documents about numbering policy of region id.
> > I also check the example below.
> > http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntryTutorial.cpp
> > The example passes the region id 0 and 1.
> > I'd like to know how to decide which region is 0(or1).
> >
> > Am I missing something?
> >
> > Thanks,
> > Takatoshi
>
> Hi,
>
> The region ids are numbered in the order of the initial_state typedef:
>
> typedef boost::mpl::vector<Start1,Start2> initial_state;
>
> Start1 will be the initial state of the first region (id 0), Start2 the
> initial state of the second region (id 1).
Thanks, I understand.
I believe if I pass the out of range value then compile error should occur.
And I tested.
0 and 1 are OK. (expected)
-1 is NG. (expected)
But 2 is OK. (unexpected)
3 or more is NG. (expected)
I'm not expert of msm's implementation.
I suspect that
state_machine.hpp:(2256)
BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index <= nr_regions::value);
should be
BOOST_STATIC_ASSERT(find_region_id<typename StateType::wrapped_entry>::region_index < nr_regions::value);
> Alternatively, you can omit the id and let MSM build a graph using mpl_graph
> and find this out for you (which will work if your pseudo entry is somehow
> connected to the initial state). Please note however that there is a
> compile-time cost for this.
Great!! This is the function that I really want to.
>
> HTH,
> Christophe
P.S.We met BoosoCon2010, how are you?
Regards,
Takatoshi
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk