Hi Christophe, Thank you very much for your feedback and time. I appreciate it a lot. Yea, I like having everything visible on the transition table and therefore I put initial states as well entry/exit actions there. I know you have a different view on that, however, I find it easier to follow this way. Declare events on the fly its easy to do, however, I don't think it will bring much value as events can be accessed outside the transition table as well as they, most likely, will hold some data. Therefore, I'm not sure about it. Might be useful to have both options tho. I would love to compare MSM-lite/MSM-eUML to eUML2, however I haven't seen it yet besides some code in the emails. Can you share a link to the eUML2 version, please? I will defo add benchmarks for it. I don't see any problem with that as MSM-lite is open source. I also offer my help in designing and/or coding. Well, I would like to keep the core of the library as small as possible as in my experience a lot of users are actually not using as many features. Having said that, I have no problems adding new features via policies/extensions. Moreover, MSM-lite is already used in some of the top growing mobile games, but yea, I do agree that some users would like to see more features. Anyway, are there any specific features you are talking about which are so essential. I know that defer/history might be useful, but I don't see much more features in MSM, besides explicit/fork states? I totally admire MSM design. I really liked the separation between back and front end. I have even implemented some extensions myself: * dependency injection support (https://github.com/krzysztof-jusiak/msm) * testing support (https://github.com/krzysztof-jusiak/msm/tree/master) And I also followed this approach in MSM-lite; it's not stated explicitly but it might be found there. Although it would be interesting to incorporate with MSM I'm afraid it's not possible with the current MSM as MSM-lite has a different approach. Especially back-end is achieved in a different way which is not compatible with MSM. While MSM-lite front-end still produces transitions-like types it holds objects and relay on dependencies to be injected. All in all, MSM-lite it's quite different than the current version of MSM. It maybe would be possible with a new version of MSM, however there is no such a thing yet, is it? Thank you again for your feedback! Cheers, Kris On Sun, Jan 31, 2016 at 9:18 PM, Christophe Henry-2 [via Boost] < ml-node+s2283326n4683114h53@n4.nabble.com> wrote:
Hi Kris,
I have recently released 1.0.0 version of experimental C++14 Boost.MSM-lite. Your scalable C++14 header only eUML-like meta state machine library with no dependencies, which outperform Boost.MSM - eUML in: - faster compilation times - up to 60x times faster! - smaller executable size - up to 15x smaller - slightly better performance - smaller memory usage - short error messages
I find it quite nice. The idea is very interesting. Minor nitpicks, I find weird mixing strings and <> syntax and the trick about inital states, but it's really a matter of taste. It would also be good to avoid having to declare events separately. It would be interesting to see how it fares against the eUML successor, eUML2 written using metaparse.
I do plan to rewrite parts of MSM and have a second look at eUML later this year, so if you don't mind, I might use some of your ideas.
I'm wondering where you want to go from there. Rewriting all of MSM is quite some work. But keeping the library lite is not really an option if you want more than a toy library because most potential users will want more features.
Actually, the whole idea of dividing MSM in back and front ends was exactly to allow front-ends like yours as extensions. Would you be interested in doing this instead? If changes in back-end are necessary, why not? It has to be done anyway, as most of the library was written 7-8 years ago. It might mean that there will be a pre and post C++14 versions, but I don't think it matters.
Cheers, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------ If you reply to this email, your message will be added to the discussion below:
http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... To unsubscribe from [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?, click here http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4683016&code=a3J6eXN6dG9mQGp1c2lhay5uZXR8NDY4MzAxNnwtMTY0MTkzNTIwMA== . NAML http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
-- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-M... Sent from the Boost - Dev mailing list archive at Nabble.com.