Re: [boost] [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?

Subject: Re: [boost] [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?
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2016-02-07 12:24:32

On February 6, 2016 3:59:30 PM EST, Kris <krzysztof_at_[hidden]> wrote:
> 
> I have encountered one ackward thing with the usage of [shift
> operators] with data events.
> 
> src + event<some_event_data> >> dst // '> >>' is quite unfortunate
> combination here

How ironic. We got a new rule in the language to allow for multiple >'s to be considered template argument list delimiters, but it won't help here. Such are the problems of EDSLs.

So far, we have these options:

1)
d = s + e[g]/a
s + e[g]/a = d

2)
d << s + e[g]/a
s + e[g]/a >> d

The choices are limited. Another pair that comes to mind is <= and ->.

3)
d <= s + e[g]/a
s + e[g]/a -> d

Those are directional and the = vs. - asymmetry might be a good thing.

The last pair I can suggest is the following:

4)
d = s + e[g]/a
s + e[g]/a -> d

1) is strange given that we expect assignment to be to the expression on the LHS.

2) has the template argument list and shift operator parsing issue. I always put a space on either side of binary operators, so that wouldn't actually affect me.

3) is only troubling due to the asymmetry in the number of lines between = and -.

4) involves normal assignment semantics in the one case and evokes the new return type function syntax in the other.

The imbalance between the syntaxes for 3) and 4) may not be a big deal since users will adopt one or the other. An issue arises when reading our maintaining the code of someone using the opposite syntax, of course.

My favorite of these is 2).

___
Rob

(Sent from my portable computation engine)