Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Darryl Green (darryl.green_at_[hidden])
Date: 2009-12-14 20:07:36

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
>