Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-23 07:29:59

Hello Andreas,

Saturday, December 23, 2006, 1:16:14 PM, you wrote:

[snip]

>> Agreed, that's why I decided not to delete states during transitions.
>> If some variables need to be reset when the state is being left, a
>> user may implement such logic in the appropriate handler function.

> In your library, is there any way to do this automatically, a la RAII?

> I'm asking because in my experience, you often need to acquire a
> resource upon state entry and release it upon state exit. It's
> error-prone when you need to release explicitly, just as it is
> error-prone when you need to manually release resources at the end of a
> block scope. That's why Boost.Statechart has this strict state-exit to
> destructor mapping. If you need a variable to live longer you push it
> into an outer state, just as you do with a variable allocated on the
> stack when you push it into an outer scope. Yes, this is suboptimal in
> the sense that other inner states of the outer state can then also
> access said variable, but the same is true for stack variables.

No, there's no automatic way to do this in my lib. Both approaches
have their pros and cons.

But some degree of automation may be achieved with little effort on
user's behalf. A state may inherit some base class which will contain
a stack of function objects to invoke when the state is left. Such
stack is already implemented in my ScopeGuard library that I have yet
to reintroduce (it was introduced long ago but due to some personal
reasons I couldn't finish the library submission process). And this
base class may also define the default handler of leaving the state
that will call function objects in that stack. And since every state
may inherit such base class, this functionality is written only once.

The only thing user will have to do then is to push a functor to the
stack that will release the resource in state exit. This may be done
right in the place of the resource acquirement.

I understand, this is not a complete automatization, but to my mind
this might help to elide coding mistakes you were speaking of.

>> Just a thought of similar functionality support in Statechart.

[snip the code illustration]

> I'd hate to add yet another template parameter, but the same could be
> achieved via specializations of a template (suggested long ago by Dave
> Abrahams):

> In simple-state.hpp:

> template<class State>
> class private_state_context {}; // Probably needs a better name

> template< class MostDerived, ... >
> class simple_state
> {
>   // ...
>   private_state_context< MostDerived > & private_context();
>   const private_state_context< MostDerived > & private_context() const;
>   // ...
> };

> If a user needs a private context for a state, she can specialize the
> private_state_context template for said state. It should be pretty easy
> to add something like this. The only problem is that every added feature
> also increases the opportunities for abuse and confusion. I'll think
> about this some more and then maybe add it to the to-do list.

That solution would be fine too.

[snip other parts]

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]