It seems to me that waiting to add a great library until some particular compiler supports it isn't a great strategy. Msm works on our production compiler, and it seems to me that the compiler support is documented.
I agree. Besides, if not used, eUML will wait long for compiler support. Compiler writers do need some users complaints as I just saw a few weeks ago.
If we fear rejection due to incorrect usage by potential users who haven't read the documentation, perhaps the library could have some built-in support for detecting compilers that are known not to work and issue a coherent compiler-time error message.
I think it's a good idea! EUML could simply refuse to compile if provided the wrong compiler.
So long as MSM works on multiple, highly-regarded compilers, and its failure on others can be demonstrated reasonably to be due to failure to comply with the standard, then its portability will have been demonstrated. If it only works on one compiler, then its portability case is diminished.
EUML compiles well on g++4.3, and reasonably well on VC9/10 and g++4.4. Darryl, I understand your point and appreciate that you want to protect eUML but I think that propagating it is the best solution to make compilers improve. More warnings in the doc would also help.
On Mon, 2009-12-14 at 21:46 +0100, Christophe Henry wrote:
It seems to me that waiting to add a great library until some particular compiler supports it isn't a great strategy. Msm works on our production compiler, and it seems to me that the compiler support is documented.
I agree. Besides, if not used, eUML will wait long for compiler support. Compiler writers do need some users complaints as I just saw a few weeks ago.
That is an important point.
If we fear rejection due to incorrect usage by potential users who haven't read the documentation, perhaps the library could have some built-in support for detecting compilers that are known not to work and issue a coherent compiler-time error message.
I think it's a good idea! EUML could simply refuse to compile if provided the wrong compiler.
It isn't just the "wrong compiler issue". I'm sorry I made this silly mistake and clouded the issue. From the docs: -------------------------- g++ 4.x: Boring compiler, almost all is working almost as expected.... I only found two ways to break the compiler: · Add more eUML constructs until something explodes. ..... On the minus side, the generated code seems to be huge compared to what VC generates. You can test your compiler’s decltype implementation with the following stress test and reactivate the commented-out code until the compiler crashes. ----------------------------------- I don't find the above at all satisfying or encouraging for production use. This is an experimental feature until compiler (and/or compiler work around/metaprogramming "optimization" stops what is considered to be the "best" compiler for this from "exploding" under relatively moderate "stress". Also, the fact that Microsoft's compilers have bigger issues makes this a serious risk in my opinion. Anyway, I hope that clarifies my concern is not primarily with the failure to compile on older gcc versions.
So long as MSM works on multiple, highly-regarded compilers, and its failure on others can be demonstrated reasonably to be due to failure to comply with the standard, then its portability will have been demonstrated. If it only works on one compiler, then its portability case is diminished.
EUML compiles well on g++4.3, and reasonably well on VC9/10 and g++4.4.
Darryl, I understand your point and appreciate that you want to protect eUML but I think that propagating it is the best solution to make compilers improve. More warnings in the doc would also help.
Agreed. It might be enough to simply make it very clear that this is at the bleeding edge of compiler capabilities. I also hope that when it becomes more practical to use eUML you will be able to extend and improve it based on more use/review. I don't believe it has had enough of either to consider the interface stable even though I suspect there won't need to be major/breaking changes to basic existing syntax (once a decision is made on which syntax that is!). I can accept eUML as an experimental library.... Does that help? Oh - I also neglected to suggest that a better name for euml is badly needed. UML to me includes statecharts as an important but small part of the notation. To some of my colleagues the UML statechart notation is completely unknown, despite familiarity with other parts of UML. Can a name that more specifically describes euml's domain as being in fsm/statechart description be selected? Or even a completely non-descriptive name relying on the containment within msm to define scope? Something like msm::coolfront (or is that ffsm::coolfront) would do.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Christophe Henry -
Darryl Green