December 2009 - Boost - lists.preview.boost.org

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

02 Dec '09

Hi Andreas, > It doesn't, but this seems to be beside the point anyway. You wrote (in an > unquoted part) that Msms behavior with respect to storage in states is hard > to emulate with SC. Simon only showed that it isn't (unless Simon and I are > missing something). But (as you wrote yourself in this excellent rationale) if you have to move the data from state to fsm you lose part of the benefit of state-storage, right? OTOH you get the advantage of automatic destruction. Even … [View More]

2 1

Wireshark Dissector for Boost
by Rick Bywater 02 Dec '09

02 Dec '09

Hello all, I am part of a project that is using Boost for serialization over a UDP interface. In concert with that effort, I am writing a Wireshark dissector to decode these packets as they transit the network. So, my question is, has someone already written a C dissector to handle these packets? If not, does anyone have any advice on how to proceed with writing one? -- Best Regards, Rick Bywater Lead Member of Technical Staff Tecore Networks Phone: +1 321 953 6794 Fax: +1 321 676-9914 email: rbywater(a)tecore.com

1 0

[multiarray] please review patch for ticket #1045; adds member swap
by Rhys Ulerich 02 Dec '09

02 Dec '09

Any MultiArray maintainers out there? I've prepared a patch to add swap for multi_array_ref and multi_array. This is a longstanding feature request (https://svn.boost.org/trac/boost/ticket/1045) The patch is attached to the ticket. If possible, I'd like to get the patch reviewed, revised as necessary, and included in 1.42. Thank you for your time, Rhys

1 0

[msm] Review
by Franz Alt 02 Dec '09

02 Dec '09

Hello Boost! This is my review for the MSM library: * What is your evaluation of the design? I've used MSM quite a while. I've already used MSM 1.x and also the new 2.0 since a few weeks. In this time I've written some own state machines, played with the samples contained with MSM 1.x/2.0 and also made some comparisons with the Boost.Statechart library. I've run the state machines I've build on standard desktop PCs as well as on embedded systems (MIPS with ~300 MHz and ARM with ~50 MHz).… [View More] On all platforms MSM made a good picture and always worked as expected. I'm not a guru in UML state charts but I've tried to use as much features of MSM as I could. * What is your evaluation of the implementation? I've looked into the main parts of the source code of MSM 1.x and a little bit of MSM 2.0. I've welcome the front- and back-end at 2.0 and the omission of the CRTP pattern (CRTP = The Curiously Recurring Template Pattern). My experience in template metaprogramming is quite limited but as I've tortured myself with CRTP a long time I knew that it's handling is quite hard sometimes. The font- and back-end at 2.0 improved the readability of MSM very much. Or should I say it improves the readability of some parts of the MSMs source code!? Because the source code of MSM 2.0 is very hard to read and understand at some places. But it's wonderful to see that metaprogramming stuff working ;-) * What is your evaluation of the documentation? I think that the documentation could be better than it is at the moment. For my taste "one" big documentation isn't nice to read. In Boost there are existing more nicely documentations like Boost.Proto or Boost.Spirit. It's a matter of taste but I think it could be an improvemet for Boost if all libraries documentations has (nearly) the same visual style. But this shouldn't be discussed here at this review. * What is your evaluation of the potential usefulness of the library? I think MSM is very useful for every professional C++ developer. Especially for state machines on embedded systems MSM could be a real improvement with it's O(1) complexity. I've made a comparison of MSM against Boost.Statechart and a state machine generated with IBM's Rational Rhapsody tool. The state machine for this comparison was the simple CD player example delivered with MSM. The results of this comparison and the source code - expected the libraries to build the Rhapsody example - I've attached to this mail. The conclusion at this test was that MSM is about 5 times faster than a state machine generated with IBMs Rational Rhapsody and a state machine with Rhapsody is 4 times faster than a state machine generated with Boost.Statechart. This was very surprisingly for my because I've thought that Boost.Statechart is much faster than the generated state machine with Rhapsody. In contrast to Boost.Statechart, MSM was approximately 20 times faster. Like I've said before I'v used the simple CD player example. A more complex state machine could lead to more interesting results of MSM, Boost.Statechart and Rhapsody. But this need some extra time that I don't have at moment. Another very important fact is that MSM uses very much compiler ressources. The problem here is that state machines with too much states and/or transitions could lead to the situation that the compiler runs out of memory and the state machine couldn't be build. I think this is only a problem of time. Further compiler versions could be more cooperative with MSM than today compilers. I think MSM is perfectly for small and medium static state machines and Boost.Statechart is good for dynamic and very big state machines. But this is only a thesis from myself and I think this should be evaluated in more detail. But this shouldn't be part of this review. A very big improvement for me is the eUML "language" at MSM 2.0. It's takes getting used to use it but I think it's such a cool think that I don't know how I've written state machines before without eUML :-) Ok, a little bit hamed but I think writing state machines with eUML could be such a big improvement for every application. * Did you try to use the library? With what compiler? Did you have any problems? I've used the library for several tests. I've used MSVC 9 and GCC 4.3/4.4. I've detected no problems with MSM. The only "problem" was that mistypes could lead to compiler errors with pages of (useless) informations. But this isn't a problem of MSM. This is more a problem of template metaprogramming. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've used MSM 1.x quite a long time. For this review I tried to use the new 2.0 and some of the new features (like eUML). I've already tried to use MSM on embedded systems like on MIPS and ARM platform. I've already tried to make a in-depth study but the MSM source code is very hard to understand. * Are you knowledgeable about the problem domain? I'm not a guru in UML state machines but I know the basics and used state machines quite a long time. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. I think MSM is an enrichment for Boost. MSM beates IBMs Rational Rhapsody! And the best, it's free, it's metaprogramming and it's Boost :-) Writing state machines make so much fun with MSM and the knowledge that it's O(1) is the best a software developer could wish. Best regards Franz // MsmSimple.cpp : Defines the entry point for the console application. // #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/state_machine_def.hpp> namespace msm = boost::msm; namespace mpl = boost::mpl; #include <iostream> #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif namespace test_fsm // Concrete FSM implementation { // events struct play {}; struct end_pause {}; struct stop {}; struct pause {}; struct open_close {}; struct cd_detected{}; // Concrete FSM implementation struct player_ : public msm::front::state_machine_def<player_> { // no need for exception handling or message queue typedef int no_exception_thrown; typedef int no_message_queue; // The list of FSM states struct Empty : public msm::front::state<> { // optional entry/exit methods template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Empty" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Empty" << std::endl;*/} }; struct Open : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Open" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Open" << std::endl;*/} }; struct Stopped : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Stopped" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Stopped" << std::endl;*/} }; struct Playing : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Playing" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Playing" << std::endl;*/} }; struct Paused : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Paused" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Paused" << std::endl;*/} }; // the initial state of the player SM. Must be defined typedef Empty initial_state; // transition actions void start_playback(play const&) { } void open_drawer(open_close const&) { } void close_drawer(open_close const&) { } void store_cd_info(cd_detected const& cd) { } void stop_playback(stop const&) { } void pause_playback(pause const&) { } void resume_playback(end_pause const&) { } void stop_and_open(open_close const&) { } void stopped_again(stop const&) {} // guard conditions typedef player_ p; // makes transition table cleaner // Transition table for player struct transition_table : mpl::vector< // Start Event Next Action Guard // +---------+-------------+---------+---------------------+----------------------+ a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , open_close , Open , &p::open_drawer >, a_row < Stopped , stop , Stopped , &p::stopped_again >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Open , open_close , Empty , &p::close_drawer >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Empty , open_close , Open , &p::open_drawer >, a_row < Empty , cd_detected , Stopped , &p::store_cd_info >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Playing , stop , Stopped , &p::stop_playback >, a_row < Playing , pause , Paused , &p::pause_playback >, a_row < Playing , open_close , Open , &p::stop_and_open >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Paused , end_pause , Playing , &p::resume_playback >, a_row < Paused , stop , Stopped , &p::stop_playback >, a_row < Paused , open_close , Open , &p::stop_and_open > // +---------+-------------+---------+---------------------+----------------------+ > {}; // Replaces the default no-transition response. template <class FSM,class Event> void no_transition(Event const& e, FSM&,int state) { std::cout << "no transition from state " << state << " on event " << typeid(e).name() << std::endl; } }; typedef msm::back::state_machine<player_> player; // // Testing utilities. // static char const* const state_names[] = { "Stopped", "Open", "Empty", "Playing", "Paused" }; void pstate(player const& p) { std::cout << " -> " << state_names[p.current_state()[0]] << std::endl; } } #ifndef WIN32 long mtime(struct timeval& tv1,struct timeval& tv2) { return (tv2.tv_sec-tv1.tv_sec) *1000000 + ((tv2.tv_usec-tv1.tv_usec)); } #endif int main() { // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif test_fsm::player p2; p2.start(); // for timing #ifdef WIN32 ::QueryPerformanceCounter(&li); #else gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::cd_detected()); p2.process_event(test_fsm::play()); p2.process_event(test_fsm::pause()); // go back to Playing p2.process_event(test_fsm::end_pause()); p2.process_event(test_fsm::pause()); p2.process_event(test_fsm::stop()); // event leading to the same state p2.process_event(test_fsm::stop()); p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::open_close()); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "msm took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "msm took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif return 0; } #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> #include "boost/mpl/list.hpp" #include <vector> #include <iostream> #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif namespace sc = boost::statechart; namespace mpl = boost::mpl; namespace test_sc { //events struct play : sc::event< play > {}; struct end_pause : sc::event< end_pause > {}; struct stop : sc::event< stop > {}; struct pause : sc::event< pause > {}; struct open_close : sc::event< open_close > {}; struct cd_detected : sc::event< cd_detected > {}; struct Empty; struct Open; struct Stopped; struct Playing; struct Paused; // SM struct player : sc::state_machine< player, Empty > { void open_drawer(open_close const&) { /*std::cout << "player::open_drawer\n";*/ } void store_cd_info(cd_detected const& cd) {/*std::cout << "player::store_cd_info\n";*/ } void close_drawer(open_close const&) { /*std::cout << "player::close_drawer\n";*/ } void start_playback(play const&) { /*std::cout << "player::start_playback\n";*/ } void stopped_again(stop const&) {/*std::cout << "player::stopped_again\n";*/} void stop_playback(stop const&) { /*std::cout << "player::stop_playback\n";*/ } void pause_playback(pause const&) { /*std::cout << "player::pause_playback\n"; */} void stop_and_open(open_close const&) { /*std::cout << "player::stop_and_open\n";*/ } void resume_playback(end_pause const&) { /*std::cout << "player::resume_playback\n";*/ } }; struct Empty : sc::simple_state< Empty, player > { Empty() { /*std::cout << "entering Empty" << std::endl;*/ } // entry ~Empty() { /*std::cout << "leaving Empty" << std::endl;*/ } // exit typedef mpl::list< sc::transition< open_close, Open, player, &player::open_drawer >, sc::transition< cd_detected, Stopped, player, &player::store_cd_info > > reactions; }; struct Open : sc::simple_state< Open, player > { Open() { /*std::cout << "entering Open" << std::endl;*/ } // entry ~Open() { /*std::cout << "leaving Open" << std::endl;*/ } // exit typedef sc::transition< open_close, Empty, player, &player::close_drawer > reactions; }; struct Stopped : sc::simple_state< Stopped, player > { Stopped() { /*std::cout << "entering Stopped" << std::endl;*/ } // entry ~Stopped() { /*std::cout << "leaving Stopped" << std::endl;*/ } // exit typedef mpl::list< sc::transition< play, Playing, player, &player::start_playback >, sc::transition< open_close, Open, player, &player::open_drawer >, sc::transition< stop, Stopped, player, &player::stopped_again > > reactions; }; struct Playing : sc::simple_state< Playing, player > { Playing() { /*std::cout << "entering Playing" << std::endl;*/ } // entry ~Playing() { /*std::cout << "leaving Playing" << std::endl;*/ } // exit typedef mpl::list< sc::transition< stop, Stopped, player, &player::stop_playback >, sc::transition< pause, Paused, player, &player::pause_playback >, sc::transition< open_close, Open, player, &player::stop_and_open > > reactions; }; struct Paused : sc::simple_state< Paused, player > { Paused() { /*std::cout << "entering Paused" << std::endl;*/ } // entry ~Paused() { /*std::cout << "leaving Paused" << std::endl;*/ } // exit typedef mpl::list< sc::transition< end_pause, Playing, player, &player::resume_playback >, sc::transition< stop, Stopped, player, &player::stop_playback >, sc::transition< open_close, Open, player, &player::stop_and_open > > reactions; }; } #ifndef WIN32 long mtime(struct timeval& tv1,struct timeval& tv2) { return (tv2.tv_sec-tv1.tv_sec) *1000000 + ((tv2.tv_usec-tv1.tv_usec)); } #endif int main() { test_sc::player p; p.initiate(); // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; ::QueryPerformanceCounter(&li); #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { p.process_event(test_sc::open_close()); p.process_event(test_sc::open_close()); p.process_event(test_sc::cd_detected()); p.process_event(test_sc::play()); p.process_event(test_sc::pause()); // go back to Playing p.process_event(test_sc::end_pause()); p.process_event(test_sc::pause()); p.process_event(test_sc::stop()); // event leading to the same state p.process_event(test_sc::stop()); p.process_event(test_sc::open_close()); p.process_event(test_sc::open_close()); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "sc took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "sc took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif return 0; } // player.cpp : Defines the entry point for the console application. // #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif #include "Player.h" int main() { // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif Player p; p.startBehavior(); // for timing #ifdef WIN32 ::QueryPerformanceCounter(&li); #else gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { open_close oc1; p.handleEvent(&oc1); open_close oc2; p.handleEvent(&oc2); cd_detected cd; p.handleEvent(&cd); play pl; p.handleEvent(&pl); pause pa1; p.handleEvent(&pa1); // go back to Playing end_pause ep; p.handleEvent(&ep); pause pa2; p.handleEvent(&pa2); stop st1; p.handleEvent(&st1); // event leading to the same state stop st2; p.handleEvent(&st2); open_close oc3; p.handleEvent(&oc3); open_close oc4; p.handleEvent(&oc4); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "rhapsody took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "rhapsody took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif //p.handleEvent(new open_close); return 0; } /******************************************************************** Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Default //! Generated Date : Wed, 2, Dec 2009 File Path : DefaultComponent\DefaultConfig\Default.cpp *********************************************************************/ //## auto_generated #include "Default.h" //## auto_generated #include "Player.h" //## package Default //## event cd_detected() cd_detected::cd_detected() { setId(cd_detected_Default_id); } bool cd_detected::isTypeOf(short id) const { return (cd_detected_Default_id==id); } //## event stop() stop::stop() { setId(stop_Default_id); } bool stop::isTypeOf(short id) const { return (stop_Default_id==id); } //## event play() play::play() { setId(play_Default_id); } bool play::isTypeOf(short id) const { return (play_Default_id==id); } //## event pause() pause::pause() { setId(pause_Default_id); } bool pause::isTypeOf(short id) const { return (pause_Default_id==id); } //## event end_pause() end_pause::end_pause() { setId(end_pause_Default_id); } bool end_pause::isTypeOf(short id) const { return (end_pause_Default_id==id); } //## event open_close() open_close::open_close() { setId(open_close_Default_id); } bool open_close::isTypeOf(short id) const { return (open_close_Default_id==id); } /********************************************************************* File Path : DefaultComponent\DefaultConfig\Default.cpp *********************************************************************/ /********************************************************************* Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Default //! Generated Date : Wed, 2, Dec 2009 File Path : DefaultComponent\DefaultConfig\Default.h *********************************************************************/ #ifndef Default_H #define Default_H //## auto_generated #include <oxf\oxf.h> //## auto_generated #include <oxf\event.h> //## auto_generated class Player; //#[ ignore #define cd_detected_Default_id 18601 #define stop_Default_id 18602 #define play_Default_id 18603 #define pause_Default_id 18604 #define end_pause_Default_id 18605 #define open_close_Default_id 18606 //#] //## package Default //## event cd_detected() class cd_detected : public OMEvent { //// Constructors and destructors //// public : //## auto_generated cd_detected(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event stop() class stop : public OMEvent { //// Constructors and destructors //// public : //## auto_generated stop(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event play() class play : public OMEvent { //// Constructors and destructors //// public : //## auto_generated play(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event pause() class pause : public OMEvent { //// Constructors and destructors //// public : //## auto_generated pause(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event end_pause() class end_pause : public OMEvent { //// Constructors and destructors //// public : //## auto_generated end_pause(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event open_close() class open_close : public OMEvent { //// Constructors and destructors //// public : //## auto_generated open_close(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; #endif /********************************************************************* File Path : DefaultComponent\DefaultConfig\Default.h *********************************************************************/ /******************************************************************** Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Player //! Generated Date : Tue, 1, Dec 2009 File Path : DefaultComponent\DefaultConfig\Player.cpp *********************************************************************/ //## auto_generated #include <oxf\omthread.h> //## auto_generated #include "Player.h" //## package Default //## class Player Player::Player(IOxfActive* theActiveContext) { setActiveContext(theActiveContext, false); initStatechart(); } Player::~Player() { } bool Player::startBehavior() { bool done = false; done = OMReactive::startBehavior(); return done; } void Player::initStatechart() { rootState_subState = OMNonState; rootState_active = OMNonState; } void Player::rootState_entDef() { { rootState_subState = Empty; rootState_active = Empty; } } IOxfReactive::TakeEventStatus Player::rootState_processEvent() { IOxfReactive::TakeEventStatus res = eventNotConsumed; switch (rootState_active) { case Empty: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 12 //open_drawer; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(cd_detected_Default_id)) { //#[ transition 1 //store_cd_info; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } } break; case Open: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 11 //close_drawer; //#] rootState_subState = Empty; rootState_active = Empty; res = eventConsumed; } } break; case Stopped: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 9 //open_drawer; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 2 //stopped_again; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(play_Default_id)) { //#[ transition 3 //start_playback; //#] rootState_subState = Playing; rootState_active = Playing; res = eventConsumed; } } break; case Paused: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 8 //stop_and_open; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 7 //stop_playback; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(end_pause_Default_id)) { //#[ transition 6 //resume_playback; //#] rootState_subState = Playing; rootState_active = Playing; res = eventConsumed; } } break; case Playing: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 10 //stop_and_open; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 4 //stop_playback; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(pause_Default_id)) { //#[ transition 5 //pause_playback; //#] rootState_subState = Paused; rootState_active = Paused; res = eventConsumed; } } break; default: break; } return res; } /********************************************************************* File Path : DefaultComponent\DefaultConfig\Player.cpp *********************************************************************/ /********************************************************************* Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Player //! Generated Date : Tue, 1, Dec 2009 File Path : DefaultComponent\DefaultConfig\Player.h *********************************************************************/ #ifndef Player_H #define Player_H //## auto_generated #include <oxf\oxf.h> //## auto_generated #include "Default.h" //## auto_generated #include <oxf\omreactive.h> //## auto_generated #include <oxf\state.h> //## auto_generated #include <oxf\event.h> //## package Default //## class Player class Player : public OMReactive { //// Constructors and destructors //// public : //## auto_generated Player(IOxfActive* theActiveContext = 0); //## auto_generated ~Player(); //// Additional operations //// //## auto_generated virtual bool startBehavior(); protected : //## auto_generated void initStatechart(); //// Framework operations //// public : // rootState: //## statechart_method inline bool rootState_IN() const; //## statechart_method virtual void rootState_entDef(); //## statechart_method virtual IOxfReactive::TakeEventStatus rootState_processEvent(); // Stopped: //## statechart_method inline bool Stopped_IN() const; // Playing: //## statechart_method inline bool Playing_IN() const; // Paused: //## statechart_method inline bool Paused_IN() const; // Open: //## statechart_method inline bool Open_IN() const; // Empty: //## statechart_method inline bool Empty_IN() const; //// Framework //// protected : //#[ ignore enum Player_Enum { OMNonState = 0, Stopped = 1, Playing = 2, Paused = 3, Open = 4, Empty = 5 }; int rootState_subState; int rootState_active; //#] }; inline bool Player::rootState_IN() const { return true; } inline bool Player::Stopped_IN() const { return rootState_subState == Stopped; } inline bool Player::Playing_IN() const { return rootState_subState == Playing; } inline bool Player::Paused_IN() const { return rootState_subState == Paused; } inline bool Player::Open_IN() const { return rootState_subState == Open; } inline bool Player::Empty_IN() const { return rootState_subState == Empty; } #endif /********************************************************************* File Path : DefaultComponent\DefaultConfig\Player.h *********************************************************************/ CD-Player example Each test was executed several times. The times are accumulated and divided by the amount of executed test runs to build an median value. ============================================================================== 100 loops of 11 transitions (10 runs) sc took in s:0.00039614 sc took in s:0.000461721 sc took in s:0.000461721 sc took in s:0.000553632 sc took in s:0.000485257 sc took in s:0.000415276 sc took in s:0.000773003 sc took in s:0.000579124 sc took in s:0.000709448 sc took in s:0.00036513 --> ~ 0.000520045 s msm took in s:1.04762e-005 msm took in s:8.93968e-006 msm took in s:8.24127e-006 msm took in s:8.31111e-006 msm took in s:9.91746e-006 msm took in s:2.31873e-005 msm took in s:2.22095e-005 msm took in s:8.38095e-006 msm took in s:1.66222e-005 msm took in s:2.08825e-005 --> ~ 1.37E-05 s rhapsody took in s:4.5746e-005 rhapsody took in s:5.28e-005 rhapsody took in s:8.73714e-005 rhapsody took in s:8.73016e-005 rhapsody took in s:5.27302e-005 rhapsody took in s:6.19492e-005 rhapsody took in s:5.27302e-005 rhapsody took in s:6.92825e-005 rhapsody took in s:4.59556e-005 rhapsody took in s:5.27302e-005 --> ~ 6.09E-05 s Result for 100 * 11 transitions: SC 0.5200 ms Rhapsody 0.0609 ms MSM 0.0137 ms ============================================================================== 1000000 loops of 11 transitions (3 runs) sc took in s:1.93943 sc took in s:1.93943 sc took in s:1.99496 --> ~ 1.95794 s msm took in s:0.0741568 msm took in s:0.0988071 msm took in s:0.0772959 --> ~ 0.08341 s rhapsody took in s:0.453220 rhapsody took in s:0.541500 rhapsody took in s:0.474185 --> ~ 0.48964 s Result for 1000000 * 11 transitions: SC 1.95794 s Rhapsody 0.48964 s MSM 0.08341 s ============================================================================== 10000000 loops of 11 transitions (3 runs) sc took in s:19.5358 sc took in s:19.6668 sc took in s:19.7063 --> ~ 19.6363 s msm took in s:1.059320 msm took in s:0.792874 msm took in s:0.870431 --> ~ 0.90754 s rhapsody took in s:4.95632 rhapsody took in s:5.02131 rhapsody took in s:4.87564 --> ~ 4.95109 s Result for 10000000 * 11 transitions: SC 19.63630 s Rhapsody 4.95109 s MSM 0.90754 s [View Less]

1 0

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) … [View More]directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir. [View Less]

9 63

[spirit/karma] missing specialization for char types in numeric_utils.hpp
by Robert.Macketanz＠rohde-schwarz.com 02 Dec '09

02 Dec '09

Hi, while testing some stuff using the karma generator like this >>> template <typername T> void do_calculations() { char buf [65]; // this is enough to display any of the numbers T val = value_getter(); char * ptr = buf; boost::spirit::karma::generate( ptr, boost::spirit::karma::int_, val ); *ptr='\0'; std::cout << buf << std::endl; } <<< the compiler (MSVC 2005) gave me errors when T was any of the "char" family about ambiguous … [View More]

2 1

[MSM] Review
by Kenny Riddile 01 Dec '09

01 Dec '09

This is my first time reviewing a Boost submission, so I'll do my best :) First of all, I'm not going to compare MSM to StateChart for two reasons: 1) I haven't used StateChart 2) I see them both as being individually useful, even if they can solve some of the same problems. Is there not overlapping functionality in many STL containers? Still, they're all well-suited to particular problems. - What is your evaluation of the design? I have been using MSM on and off since January 2009 … [View More]and have seen the design evolve as new features were added. I first used it in a simple iPhone game which required a way to "update" an FSM's current state. This feature was generalized into the current ability to "visit" the current state. The more I used the library and communicated with the author, it became clear that the design, and any changes to it, were thoroughly thought-out. I especially like the clarity with which one defines an FSM (specifically the transition table). The fact that a single instance of each state is default-constructed and bound to the FSM's lifetime is something that should be carefully considered when deciding if MSM fits with a particular use-case. It was suggested in another review thread that a mechanism to optionally pass prototypical states in to a new FSM be added so that states didn't have to be default-constructible. I agree with this suggestion. Aside from that, the design has made it intuitive to accomplish everything I've tried to do with MSM. - What is your evaluation of the implementation? I've only looked at the implementation a few times over the last year when trying to track down apparent bugs (which were all promptly fixed). Aside from those instances, I try to avoid looking at things that hurt my brain. I've seen the code in "C++ Template Metaprogramming" that MSM is based on, and consider it sound. Is there a test suite for MSM? Do these tests pass on all platforms officially supported by Boost? - What is your evaluation of the documentation? The documentation was invaluable when I was first playing around with MSM. The examples are concise and clearly demonstrate what they are meant to. I would prefer that the documentation be broken into multiple pages similar to other released libraries. - What is your evaluation of the potential usefulness of the library? I think MSM is useful because I have found uses for it. My only significant experience with MSM has been in mobile game development, and I have used MSM in one shipped iPhone game. It has worked very well in particular situations, such as simple AI for a single game entity. The "staticness" of an MSM FSM is advantageous in this example, since constantly creating and destroying states can noticeably affect performance when a large number of entities are present in a simulation. Conversely, I wouldn't use MSM to control the high-level application flow of a game. I've found that the persisted states and default-constructibility requirement end up being hoops to jump through that just aren't worth it in this case where state transition speed isn't a concern. Long compile times in the name of run-time performance have never bothered me either. I can always upgrade my development machine, but a customer can't upgrade their iPhone. - Did you try to use the library? With what compiler? Yes. I've used MSM with MSVC9 and GCC compiling for the iPhone. - Did you have any problems? I've found a bug or two when using MSM, but they were always fixed promptly and correctly. There is of course the transition table size limitation imposed by mpl::vector and the compiler. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've used an earlier version of the library in a shipped product, and I've played with recent versions prior to the review. - Are you knowledgeable about the problem domain? I understand how FSMs work and what they can be used for. - Do you think the library should be accepted as a Boost library? Yes, I absolutely think MSM should be accepted into Boost, and will continue to use it regardless of the review results. I would like to see the documentation restructured and the default-constructibility requirement for states removed via the means already described. My vote for acceptance is not contingent on these requests. [View Less]

1 0

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

01 Dec '09

Hi Simon, >I agree that the feature can be costly. I don't have a lot of experience with fsms with very tight time constraints though - > SC seems to meet our time requirements (ie the state machine itself is much faster than the other operations we perform). Sure but Msm is a general-purpose library and can therefore not allow itself not to be performant. Quite a few Msm users are from the embedded world and performance does matter there (anyway, this is C++ so it always does, right? ;… [View More]-) ). Msm also proves that thanks to metaprogramming, a library can bring ease of use and speed. >>+ your state data is always available. In my experience, state data is >>not only needed in the entry or when the next event is processed, but >>during a transition or even at some time after a transition. This >>means, that you have, during a transition, access to data from the >>source or the target state. > This is simple to emulate in SC. The state data can be owned by the outer state, or by the state_machine itself. Sure, but then the statechart documentation itself makes a pretty good point why this is less than ideal(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/faq.html#Sta…. In short, this workaround means that some data saved this way in the top-level fsm will only have a meaning in some of the states of this fsm. Doesn't this pretty much defeat the concept of state local storage itself? >>+ combined with the visitor, you can at any time access data from the >>currently active state and build a generic way to do something with >>state data. >Granted. Personally though, I prefer to keep my fsm opaque, and force the use of events and actions > to update and monitor the fsm respectively. Any other method (in our application) is a violation of the desired encapsulation. I should have explained a bit better. What you write is exactly what the visitor concept is for. It allows you to delegate to the active state(s) an action to execute at any time, without even needing an event. Thus you keep your fsm opaque and more robust. And all this happens without rtti or virtual calls. >IMO the lack of state local storage is actually a relatively minor issue. The big ticket issue for me is its ability >(or rather, the compiler's ability) to create large state machines. With SC, I might create a 50 transition state machine. >Over time, normal maintenance might add another 10 or 20 transitions. This isn't a big deal. >However, I'd be less likely to start developing such a state machine with msm for fear that any additional transitions might push the compiler 'over the edge'. Granted, the limit is, for the moment, the compiler. I managed yesterday 150 transitions with g++4.3. If Msm becomes part of Boost and we report to Microsoft that g++ is beating them that much, they might find some motivation to fix their bug. If you read the beginning of this thread again (the review), you'll see that the reviewer managed 15 states and 80 transitions with VC9, which already starts being a reasonable-sized state machine. Msm is clearly not only for very small machines. >So for medium to large state machines, I would choose SC. > For very small state machines, I might be tempted to choose a C style hand written state machine > to avoid the learning overhead for such a trivial application (though Euml is cool enough that I might overcome that). As you already seem to use SC quite much, learning Msm should not be such a large overhead. If you try, please let me know how it went. And if eUML is tempting you to use Msm, then it did its job :) Christophe [View Less]

2 1

[fiber] new version in vault
by Oliver Kowalke 01 Dec '09

01 Dec '09

I've uploaded a new version of boost.fiber - main features are: - multiple schedulers can be used in one thread - user can provide its own scheduler implementation as template argument to class scheduler - classes disable_interruption and restore_interruption moved into namespace boost::this_fiber regards, Oliver

6 29

BOOST_MSVC vs. _MSC_VER wrt #pragma warning
by Emil Dotchevski 01 Dec '09

01 Dec '09

I understand that BOOST_MSVC is needed to detect MSVC because other compilers besides MSVC define _MSC_VER. But what about #ifdefing #pragma warning, should it use _MSC_VER or BOOST_MSVC? The reason why the ifdefing is needed is to prevent GCC and other compilers issuing a warning about #pragma warning, but presumably compilers that have _MSC_VER defined wouldn't warn about that, would they? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[1.42.0] Release branch open for merges
by Beman Dawes 01 Dec '09

01 Dec '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the … [View More]

3 3

[msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Juraj, First of all, thank you for being the first one to write a review. I imagine it's not an easy thing. Thank you also for bringing a few very interesting points to the discussion. I'm happy to build on them and hope to finally start some discussion. >MSM does lack some of the SC functionality. >There is no state-local storage in SC sense, as all states are >constructed when main state machine is constructed. This can be easily >worked around though. As this point is being … [View More]brought for the second time, I'd like to spend some time on it. You already have state local storage with msm, just not like with SC. Like SC, msm defines states as classes, meaning they can have data. There is however one important difference with SC. Msm builds all the states upon state machine creation. States are not destroyed until state machine destruction. This has advantages and disadvantages: - states must be default-constructible - you might need to heap allocate the state data if you cannot initialize it at state construction. + speed: states don't need to be constructed again and again. Constructing a state (and its attributes) each time it becomes active can be costly, even if memory allocation can be optimized. + your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state. + combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data. + you can build examples like the iPodSearch where states keep iterators to some container, thus keeping information from an iteration to the next one. + you avoid having data released inside a destructor. Knowing that destructors should not throw, it makes your life easier. + on_entry is templatized, giving you more leeway to add event-specific handling. + your event data is not lost upon state entry Msm's handling is hard to emulate with SC, on the other hand, SC's handling is easy to emulate with Msm. It has its drawbacks but all considered, I think it is a superior solution. >It is impossible to stop event from propagation (SCs discard_event()) >without actually changing state. It is true. At the moment you cannot. Actually, I don't think UML foresees this possibility. OTOH, I think it is an interesting one and will be happy to borrow it from SC. I think that using the transition table is one of Msm's biggest strengths so I offer to add a row or a functor allowing event propagation to be stopped. You could even give it a guard, thus allowing fine-grained transition conflict resolution. > You cannot conditionally defer an event. Again you're right. I think UML doesn't foresee this either, but I also like it and will also borrow it from SC. You offered the idea of a d_row (deferred row) or dg_row (the same with a guard). I think it is the best possibility with the simplest front-end and makes deferred events a first-class citizen, being in the transition table and coming into play during conflict resolution. For the functor and eUML front-ends I think it could be done as an execution row. Something like: State1() + Event1() / defer_() Seems an interesting starting point. >There seem to be some differences on how event deferral is handled when > composite states are used. This part is a still bit mysterious to me. I will add a part about the dispatch algorithm to the documentation. >Aesthetically - I'm not a great fan of one big fat html documentation > and would prefer to have it broken down and cross-referenced as most > boost libraries docs are organized, but this is just a minor issue. If Msm is accepted into Boost, I'd probably move to BoostBook anyway, so this will be done at this time. > The author seems masochistic enough to try to tackle this. :) Sure :) and I don't mind the term at all :) Thanks for the review and the very good points you brought during the last weeks! Regards, Christophe [View Less]

3 2