Hello Peter, Wednesday, January 10, 2007, 10:58:32 PM, you wrote:
Andrey Semashev wrote:
Hello Peter,
Wednesday, January 10, 2007, 12:02:17 AM, you wrote:
You should also consider not extending the critical sections beyond the minimum necessary, as in
locking_state_machine& operator= (locking_state_machine const& that) { scoped_lock that_lock( that.m_Mutex ); base_type tmp( that ); that_lock.unlock();
scoped_lock this_lock( m_Mutex ); tmp.swap( *this ); this_lock.unlock();
return *this; }
I thought about something like this and decided not to do it. The implementation has no support for "swap" and it would not be an easy and convenient for users thing to implement it. Besides, the assignment creates an additional copy of the machine which is at least not intuitive for users and may considerably increase performance cost.
Yes, after looking at your submission, I now realize that base_type is basically a tuple of states (this could be a good use case for fusion). As a side note, speaking of performance, if you want to position your library as faster than Statechart, you probably need to back that up with specific measurements. These can go in the Performance section.
Ok, I've put that in my to-do list. -- Best regards, Andrey mailto:andysem@mail.ru