From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-02-11 12:30:47
[I'm sending this again because the first version never showed up]
Alexander Nasonov wrote:
> Jonathan,
> /* I'm replying to you privately because I don't have access to my
> private
> * mailbox from work and apparently I don't want to publish my
> business
> * address on internet. As soon as I get home I'll post it to boost
> list. */
Thanks, Alexander. I'm starting to understand now. Sorry I'm so slow.
> Jonathan Turkanis wrote:
>> What I would like to know is why you want to represent overload sets
>> as compile-time collections: what sort of computations can you do
>> with them in practice? I'm not expressing any scepticism that it's
>> useful, I just want more information.
>
> Ok. Using state machine as an example:
>
> struct Fsm
> {
> Running operator()( id<1>, Passive, EvActivate ) const;
> Stopped operator()( id<2>, Running, EvStartStop ) const;
> Running operator()( id<3>, Stopped, EvStartStop ) const;
> Stopped operator()( id<4>, Active, EvReset ) const;
> // ...
> };
I assume you're using id<..>'s to distinguish signatures even if they agree at
every other position. My initial guess is that operator()'s with the same id<..>
would correspond to functions having the same name. But then I see that each
operator() seems to have a unique id<..>, which make me wonder where the
overloading is.
> Every call operator has such pattern:
>
> NewState operator()(id<N>, State, Event) const;
>
> and represents a transition from a state State to a state NewState
> caused by event Event. Transition logic is defined in the call
> operator body.
> If you were using MPL containers you would need to implement the
> logic in separate functions and pass them along the lines of
> metainformation about FSM:
> Most interesing part here is FSM generator. Using the power of MPL and
> type_traits, it gets states out of transitions, allocates storage for
> them and generates transition table. Additionally, it could take into
> account inheritance relashionship between states to allow
> superstates/substates or it could treat void return type as no
> transition (action only) or it could discard transitions under
> certain circumstances or it could turn thrown exception into event
> and process it or ... A lot of interesting things are possible,
> thanks to MPL and other boost libraries :)
> My library is supposed to do same things. The difference is that step
> 1 and 2 are now not separated and you don't have to scroll up and
> down to make sure both parts are in sync.
Okay, I think I understand this example.
I'm not so sure I see how, or if, this relates to overload resolution. In
addition to the associative sequence operators, I would expect to have a
metafunction that takes an argument list and determines which overload is
called.
Best Regards,
Jonathan