Hi Richard,

Is it not allowed to use derived classes as backends ?.

Actually, I don't know. I mean, I don't know of a C++ rule forbidding it, but I'm not a language lawyer. What I know is that this problem used to happen sporadically with eUML in the 2.0, but only with VC, and in this case, I see it happen also with g++ 4.4. I'd say it's a compiler bug but usually, g++ is right so I'm not sure.

I was not a ware of it. Is it mentioned in the documentation ?

Probably not because I didn't see it happen any more with MSM v2.10. It used to happen with the 2.0 and only with VC and eUML.

If only composite state machines can not be derived classes of msm:backend than this is fine because I had only one place till now which I have changed already.

We are moving inside uncharted territory. All what I can say is that it used to happen sporadically and only for eUML composites or substates. I never, in any version, saw it happen with the main fsm. Let's try to find a way around. Why do you need to use the back-end as base class? Could you elaborate? And will the need go away after I implement the previously discussed feature that you can pass to the back-end concrete substates instead of default-constructed ones? Something like what Dave suggested: player p(/* for the front-end*/ 3, "a", backend_args = ( init1=Paused("something"), init2=Playing("more data")) ); If you describe your use case, I'll try to find a solution. It'd not be the first time I find a way around compiler bugs ;-) Regards, Christophe