Boost logo

Boost :

From: Alexander Nasonov (alnsn-mycop_at_[hidden])
Date: 2004-06-05 02:45:59


Sorry for not replying earlier,

Andreas Huber wrote:

> Hi Alexander
> [skiped]
> So far I *think* I understand. You have developed a way how to
> represent/implement multimethods in C++.
That's right. A little remark: I'm not finished it yet :)

>> 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.

You're right. I missed it. Not a big problem, though. You can declare as
many testers as you need to deduce arguments of a call operator with
arbitrary arity (up to some reasonable value). They won't mess things up.

> 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).
Yep.

> Your mechanism only works with functions declared in a single class,
> right?
Correct.

> 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 like this 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).
I agree.

>
> Regards,
>
> Andreas

-- 
Alexander Nasonov

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