Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-06-01 11:48:35


Hi Alexander

> Although my idea is supposed to solve multimethod support for dynamic_any it
> might be useful in FSM library.
> What I'm trying to build in last two weeks is some sort of typelists for
> overloaded function set. Each function is identified by overload_id<N>
> class with unique N. For example:
>
> struct read_number_transitions
> {
> // Signatures has the form NewState (OldState, Char)
> Positive operator()(overload_id<0>, StartState, Plus) const;
> Negative operator()(overload_id<1>, StartState, Minus) const;
> Positive operator()(overload_id<2>, StartState, Digit) const;
> Positive operator()(overload_id<3>, Positive, Digit) const;
> Negative operator()(overload_id<4>, Negative, Digit) const;
>
> static std::size_t const max_overload_id = 4;
> };
>
> This approach has advantage over typelists in some cases because things are
> right in their places. In the example, every transition, on one hand, is
> represented by a call operator (this is natural, because transition is a
> function that takes old state and a char and returns a new state); on the
> other hand, argument types and return type (a signature) can be retrieved
> from the call operator.

So far I *think* I understand. You have developed a way how to
represent/implement multimethods in C++.

> The retrieval is a bit problematic but I'm working on this. The problem is a
> lack of typeof in C++. If it were available you could write:
>
> template<int N, class C, class R, class T>
> mpl::identity<R(T)> tester(R (C::*)(overload_id<N>, T) const);
> typedef typeof(tester<0>(&read_number_transitions::operator()))::type sig0;

Here you lost me, tester does not seem to accept enough parameters. I assume
that you'd need another parameter for the event. sig0 seems to have the same
problem.

I don't exactly grok what follows but I guess it describes how to retrive the
right functions given the current state type and an event type. You can then
call the function to transition to the new state (the new state is returned).
Your mechanism only works with functions declared in a single class, right?
While I can see that an FSM framework can be built on top of this mechanism, I
think I won't be able to use it in boost::fsm. A state machine implemented in
terms of my library can be spread over multiple translation units (this is a
key feature).

I think your MM implementation (nice idea, BTW) could probably be used in a
second FSM library, which is more oriented towards top-notch speed. boost::fsm
focuses more on scalability (i.e. minimization of compile times of and
dependencies in large FSMs).

Regards,

Andreas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk