
I want to apologize for the harsh language I used and the uncharacteristic loss of patience I displayed. I also wanted to let you know that I of course accept your explanation as not doing it would be suspecting you of being dishonest, which I have not been doing at any time. I admit honestly failing to understand what is the impossibility you claim, thus the confusion. I think there is no interest right now for a technical discussion but for the record, I do not accept any impossibility of any sort and the next version of MSM will include a precise example of a multi-TU fsm to illustrate my claim. I wish all of you a happy, successful new year. Christophe

Multi-TU FSMs with MSM are certainly interesting in their own right and your drive to make the impossible possible is admirable. However, if you're doing this specifically to disprove my 2005 impossibility claim (likely, since you linked to it), I should probably bring to your attention that there are 2 more conditions than just "multi-TU-ness": A. Only static dispatch must be used, see comment 1 in my previous post B. It must be possible to define states (belonging to the same FSM) in different TUs, see comments 2 & 3 C. It must be possible to define orthogonal regions (belonging to the same FSM) in different TUs, see comment 4 I think B & C are pretty clear, Statechart satisfies these since it is a part of Boost (if you're interested how, I can provide an example). For condition A to hold, you certainly can't use any in-memory function pointers (as opposed to non-type template arguments) or virtual methods, as these are commonly referred to as dynamic dispatch. Moreover, there are other methods to implement dynamic dispatch (e.g. switch-case on a variable), which would be "banned" as well. Now, I don't think that it is "mathematically" impossible to implement a C++ FSM framework that satisfies A, B & C (although one could rightly come to that conclusion when reading my 2005 post), but I do think that such a framework would be rather unwieldy to use because it seems that the user would be required to somehow manually connect the various TUs that the FSM draws its parts from. That is, at least some stuff that happens automatically in multi-TU Statechart FSMs would be left to the user in a framework satisfying A, B & C. Just my 2c, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber
-
Christophe Henry