December 2009 - Boost - lists.boost.org

[msm] choice (point) pseudo state
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - I am modifying my code generator to target MSM so that I can evaluate some larger machines and run existing test suites that I use. I do not see the concept of a choice point. Did I miss it? It looks like it can be modeled with a state having only anonymous transitions and appropriate guards. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] history pseudo states
by Michael Caisse 07 Dec '09

07 Dec '09

Hello Christophe - I am trying to understand your implementation of history. In the MSM documentation it states: "As explained in the BoostCon09 paper <cid:part1.00040908.05020506@objectmodelingdesigns.com>, Histories are weird. First, there can be just one." In the boostcon09 paper it also states [page 5]: "To be frank, History is not a completely satisfying concept. First of all, there can be just one history pseudostate and only one transition may originate from it." I'll not contend with the views of history yet. They can be a very powerful concept. What I'm unclear about is the statement that there can be just one. According to the UML specification there can be just one per composite state. That of course makes perfect sense. MSM has SubmachineStates instead of composite states; however, the same "rule" applies to both. Does MSM obey this definition or is there a further constraint? My confusion might be partially attributed to not having finished reading all of the docs. Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] eUML guard/action location
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - Just a quick question about eUML syntax. I think the concept is great. The placement of the guard and actions doesn't strike me as natural. CurrentState() + cool_event() = DestState() [Guard()]/(action()) There are a couple of reasons for this. One is the conceptual ordering of how the UML machine works. 1. In CurrentState 2. Receive cool_event 3. Check for transitions matching cool_event 4. Found match 5. Verify guards 6. Guards pass 7. Handle CurrentState exit action 8. Take transition and handle transition action 9. Handle DestState entry action 10. Reside in DestState Another reason that I find it unnatural is that the event/guard/action is associated (in my mind) first with the transition leaving the CurrentState. The transition obviously is associated with the DestState but the event/guard portions "occur" while in the CurrentState. UML already (via its notation) pulls together the event and action. What do you think about this instead? CurrentState() + cool_event()[Guard()]/(action()) = DestState() I think it more closely matches the UML syntax. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Two FSM libraries, one interface
by David Bergman 07 Dec '09

07 Dec '09

NO, this is not yet another attempt of mine to irritate people by claiming that the interfaces of Statechart and MSM are similar ;-) When evaluating MSM, both from an interface and performance (read "abuse" ;-)) point of view, I decided to create a common wrapper for both libraries, since I host this awkward notion that the mapping from such a (much more abstract and less verbose) wrapper to the underlying libraries should not vary that much. Be that due to the interfacial commonalities between the two libraries or my great mapping skills :-) Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money (or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later, as well as provide access to the actual header file. I just want to gauge the interest for such an abstraction layer *for non-complex FSM needs*. I do not claim any commutation, but at least we have a decent sub diagram with arrows from my abstract interface to each one of Statechart and MSM for non-complex cases. I currently imaginatively call this common interface "abstract_fsm.h". It preprocesses a common description to either Statechart or MSM, decided by setting either "USE_SC" or "USE_MSM". It is currently limited to non-nested machines without guards, and only handles the specification, not execution. But, the end result is pretty cool. So, hold on to you LISP hats (there will be parentheses...) and see for yourself. This is a simple FSM app using that abstraction: #include <iostream> #include "abstract_fsm.h" FSM_DEF(Machine, // The type of the FSM (Play)(Stop), // the events // The transitions (including the states) ((Stopped, ((Play, Playing, { std::cout << "starting to play" << std::endl; })) ((Stop, Stopped, { std::cout << "stopping" << std::endl; })))) ((Playing, ((Stop, Stopped, { std::cout << "staying in Stopped" << std::endl; })))) ) int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } Everything is contained in that FSM_DEF construct, including events and transitions (including the source states). One cool thing is that the actions are right there. I have no clue as to the general usability of this abstract layer, but it serves the immediate purpose of testing runtime performance of the two libraries by merely using USE_SC or USE_MSM. This application is preprocessed to this Statechart app (by using -E -DUSE_SC...): #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> struct Play : boost::statechart::event<Play> {}; struct Stop : boost::statechart::event<Stop> {}; struct Stopped; struct Playing; struct Machine : boost::statechart::state_machine<Machine, Stopped> { void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } }; struct Stopped : boost::statechart::simple_state<Stopped, Machine> { typedef boost::mpl::list< boost::statechart::transition<Play, Playing, Machine, &Machine::actStoppedPlayPlaying> , boost::statechart::transition<Stop, Stopped, Machine, &Machine::actStoppedStopStopped> > reactions; }; struct Playing : boost::statechart::simple_state<Playing, Machine> { typedef boost::mpl::list< boost::statechart::transition<Stop, Stopped, Machine, &Machine::actPlayingStopStopped> > reactions; }; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } And when preprocessing to an MSM app (by using -E -DUSE_MSM...): #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/state_machine_def.hpp> struct Play {}; struct Stop {}; struct Stopped : boost::msm::front::state<> {}; struct Playing : boost::msm::front::state<> {}; struct Machine_ : boost::msm::front::state_machine_def<Machine_> { typedef Stopped initial_state; void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } typedef boost::mpl::vector< a_row<Stopped, Play, Playing, &Machine_::actStoppedPlayPlaying> , a_row<Stopped, Stop, Stopped, &Machine_::actStoppedStopStopped> , a_row<Playing, Stop, Stopped, &Machine_::actPlayingStopStopped> > transition_table; void initiate() {} }; typedef boost::msm::back::state_machine<Machine_> Machine; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } It is worth noting that once I had wrestled with Boost.Preprocessor and created a mapping to Statechart, the MSM mapping took 14 minutes, and a lot of meta functions were common between the two cases. /David

1 0

Does anyone know what happens to all we write at home?
by Vladimir Batov 07 Dec '09

07 Dec '09

Does anyone know what happens to all we write at home? We habitually put the 'boost' license on such work. However, can your employer claim that *anything* you do belongs to "him" and to slap you with a violation of Confidentiality Agreement or Intellectual Property Agreement? V.

3 2

[rdb, fusion, profile_templates] 0.2.03 - compilation speedup
by Jean-Louis Leroy 06 Dec '09

06 Dec '09

I have uploaded version 0.2.03 to the vault. No new features this time but improvements in compilation speed. The test_odbc project took more than 4.5 minutes to build in debug mode (msvc9, ThinkPad x200s, Intel L9400 with 2 cores @ 1.86 Ghz, 4 Gb RAM) and...17 minutes on a 2Gb RAM computer ! This was becoming unbearable. After a run through profile_templates - thanks to Steven Watanabe for creating this tool ! - I replaced the fusion::maps that were used to gather clause information in sql statement templates with a simpler, less flexible, less orthogonal and less capable version of my own. The result was a 41% speedup (calculated as (old-new)/old) on the 4 Gb computer and 85% on the 2Gb one. The number of template instantiations, as reported by profile_templates, dropped from 86330 to 62771. If someone is interested I can post the complete profiling reports. I plan to focus on datetime support now... Jean-Louis

2 2

Re: [boost] [msm] Review
by Christophe Henry 06 Dec '09

06 Dec '09

Hi David, >>> 2. In Statechart, the definition of a state is coupled to the machine in which it resides >>> while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines >>> 3. In Statechart, the transitions are coupled to the from-state, and defined therein, >>> whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart >> >> This is an important interface difference, isn't it? > Yes, which is why I brought it up; see (*) below. Thanks for doing it, I see this as an important point. >* - Yes and no... As I explained in my note to Dave, I did not mean API when I wrote that dreaded sentence about the interface similarity, >I meant it in a more abstract sense. BUT, for simple cases, where we do not deal with transition guards or nested machines, >there actually is a quite close similarity even at a syntactical level. Agreed. But isn't the interface similarity mainly due to the very tightly specified problem domain and to the fact that we all use the excellent MPL tool? Of course, simple state machines using MPL will all look slightly the same, as will do those based on OO-principles with each other. When a new implementation (even based on the same tools) brings important advantages, shouldn't it be considered for inclusion? >They treat guards differently. Yes. I'll come back to it in a minute. >> Let's now add a conflicting transition, which means another possible >> transition on the same event and the same source state, with guards >> deciding which (if any) transition will be taken. >We are now arguably leaving theoretical FSM's and entering pragmatic machines :-) Sure. Theoretical FSM's are anyway about the same for all. My point is to show that differences between MSM and Statechart are subtle but play an important role. >> With MSM you'd have, for example: >> typedef mpl::vector< >> row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>, >> row<State1, Event, State3, &Machine_::action, >> &Machine_::some_other_condition> >> > transition_table; >> >> Could you now write the Statechart version for us? > No ;-) Then, I'm not an expert with Statechart but allow me to try to help ;-) I think (please correct me if I'm wrong) it'd look about like: sc::result react(const Event& evt) { if (some_other_condition(evt)) { action(evt); return transit<State3>();} else if (some_condition(evt) { action(evt); return transit<State2>();} } And this is one important difference, not just a syntactic one. With SC, the structure of the state machine is hidden in the code, which will make your conversion tool harder to write on the direction SC->MSM as the tool will not just be able to parse the code but also understand it. Add a few more actions or other piece of code and I wish your tool luck ;-) OTOH you get more flexibility. So, my point is, there are more differences that syntactic ones, as long as you make more complicated machines. I still agree with you on the point that interfaces are not "widly different" but I put this on the account of a clearly specified problem domain and the fact that most of Boost uses the same MPL tool (due its huge power. Thanks Dave, thanks Aleksey ;-) ). >Yes, there are syntactical differences and decouplings of state vs machine which makes MSM a nicer tool; >and, didi I mention that MSM is in my simple test cases six times faster? You did and I thank you for adding your own tests to the review. As an extra note, if you are ready to give up some state features and need just an enum for the states, you might want to take the FSM in the MPL book. It would probably even be possible to make from it a backend which could at some point partly support the different MSM front-ends. MSM does not yet support this solution in order to deliver a back-end supporting the state features specified by UML (again the restricted problem domain) but it is one of the backends I consider for addition. Do we agree to leave the dreaded sentence behind us and replace it with one saying that both libraries solve the same problem using a wildly different implementation with similarities in the syntax? Christophe

2 1

[chrono] type_traits/common_type and integer/ratio
by Vicente Botet Escriba 06 Dec '09

06 Dec '09

Hi, I'm looking on how to continue with the Boost.Chrono library and I would like to know if * Boost.TypeTraits could take care of the common_type class template. * Boost.Integer could take care of the ratio class template. In this way Boost.Chrono will contain only the time related facilities, duration, time_point and Clocks. In order to minimize the task and been able to purpose as soon as possible the library for review I would like to concentrate on the implementation of the standard proposal and let for a future release the facilities Beman added as * Class template timer, with typedefs: * `system_timer` * `monotonic_timer` * `high_resolution_timer` * Process clocks and timers: * `process_clock`, capturing real, user-CPU, and system-CPU times. * `process_timer`, capturing elapsed real, user-CPU, and system-CPU times. * `run_timer`, convenient reporting of process_timer results. What do you think about this approach? Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--type_traits-common_type-and-integer-ratio-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 19

Re: [boost] [msm] Review
by Christophe Henry 06 Dec '09

06 Dec '09

>> Repeating: the MSM/Statechart overlap in features and interface is quite >> unique to Boost. > > > They definitely overlap in features and also in intent, but my understanding > is that the interfaces are vastly different, and that's an important > distinguishing feature. Am I missing something? No you aren't. At first look, they seem similar, but as soon as you concretely start writing a state machine with both libraries, like Juraj could tell you (he did it), you'll start seeing that the differences are there. Of course, both use states, events and transitions but that's about all. MSM bases itself on the transition table, while with Statechart, the user writes his decisions in the react function. Composites are full state machines with MSM, a simple state with Statechart. MSM uses more metaprogramming, Statechart follows a solution with multiple translation units. Etc. etc. The point is, the interfaces differ, the normal usage even more and the "correct" way to use each (in the authors' eyes) much more as both follow a completely different philosophy, as many heated discussions showed. Christophe

4 4

arithmetic meta functions and traits
by Zachary Turner 06 Dec '09

06 Dec '09

Is there any use for something like this? Following compiles on MSVC 9.0. Despite the simplicity of the final template, it was *NOT* easy to get this working given that there's about 10 ways you should be able to do this according to the standard, but poor SFINAE support makes it next to impossible to get your compiler to accept anything. Since it doesn't do anything highly fancy, I would wager it works on GCC and other compilers as well, although it needs to be tested. struct no_type { }; #define MAKE_BINOP_METAFUNCTIONS(op, binop, traits) \ template<typename T, typename U> no_type operator op (T, U); \ template<typename T, typename U> \ struct traits \ { \ typedef BOOST_TYPEOF(T() op U()) type; \ }; \ template<typename T, typename U> \ struct binop \ { \ private: \ typedef typename traits<T,U>::type result_type; \ public: \ static const bool value = !boost::is_same<result_type,no_type>::value; \ }; MAKE_BINOP_METAFUNCTIONS(+, is_addable, addition_traits); MAKE_BINOP_METAFUNCTIONS(-, is_subtractable, subtraction_traits); MAKE_BINOP_METAFUNCTIONS(/, is_dividable, division_traits); MAKE_BINOP_METAFUNCTIONS(*, is_multipliable, multiplication_traits); Obviously you can define other operators similarly, as well as unary operators. Zach

2 4