On 9/22/2010 4:35 PM, Christophe Henry wrote:
> The subject of the day seems to be sub-domains and it's great because
> I wanted to check that a use I just made of them was correct.
> So the problem is:
> In eUML, states are terminals of my state machine domain (sm_domain).
> The domain's grammar disables as little as possible (address_of):
> struct terminal_grammar : proto::not_<proto::address_of<proto::_> >
> // Forward-declare an expression wrapper
> template<typename Expr>
> struct euml_terminal;
> struct sm_domain
> : proto::domain< proto::generator<euml_terminal>, terminal_grammar >
> Now, I just implemented serialization for state machines using
> boost::serialization which happens to define its own DSEL, archive <<
> fsm and archive >> fsm.
> As state machines are states in eUML, I created a conflict between
> both DSELs: << and >> for serialization and my own eUML, like init_ <<
> I solved the conflict by creating a sub-domain for states with a
> stricter grammar:
> struct state_grammar :
> proto::not_<proto::address_of<proto::_> >,
> proto::not_<proto::shift_right<proto::_,proto::_> >,
> proto::not_<proto::shift_left<proto::_,proto::_> >,
> proto::not_<proto::bitwise_and<proto::_,proto::_> >
> struct state_domain
> : proto::domain< proto::generator<euml_terminal>, state_grammar,sm_domain
> As init_ is in the super domain sm_domain, init_ << state is allowed,
> but as states are in the sub-domain, archive << fsm calls the correct
> boost::serialization overload.
> However, I have some doubt that what I'm doing really is ok or happens
> to be working by pure luck.
> If it's an acceptable usage, sub-domains helped me out of a tight spot
> and I'm really going to be tempted to push this further ;-)
This is really ok. I'm very glad this feature is finding real-world
uses. Push it further and send us status updates. :-)
proto mailing list