On 14/03/2011 22:12, Christophe Henry wrote:
Calling phoenix expressions from the statement module return void.
Calling phoenix expressions from any other modules return whatever ... depending on the
"C++-Sense".
It's ok, I can live with it, though I'll need to find a way around
because I do n
>Well, because it wasn't possible at the time, I assume ;)
>Times have changed since then ...
Indeed. Looks like it. :)
>> What I wanted to know:
>> - can I pass a phoenix expression to a decltype / BOOST_TYPEOF and
>> default-construct it?
>In general, no, because of various terminals that nee
On Monday, March 14, 2011 10:12:09 PM Christophe Henry wrote:
> >Calling phoenix expressions from the statement module return void.
> >Calling phoenix expressions from any other modules return whatever ...
> >depending on the "C++-Sense".
>
> It's ok, I can live with it, though I'll need to find a
On 14/03/11 22:28, Christophe Henry wrote:
.. the talk from Matt Calabrese last year at boostcon with the
MPL/Fusion hybrid
using decltype and auto. I think this is an interesting venture all in
all and should
be extended.
Yes, I have this in mind too.
I think it is worthy of *at least* consid
On Mar 14, 2011, at 5:28 PM, Christophe Henry wrote:
>> .. the talk from Matt Calabrese last year at boostcon with the
>> MPL/Fusion hybrid
>> using decltype and auto. I think this is an interesting venture all in
>> all and should
>> be extended.
Personally, I think it's interesting but I like
> .. the talk from Matt Calabrese last year at boostcon with the
> MPL/Fusion hybrid
> using decltype and auto. I think this is an interesting venture all in
> all and should
> be extended.
Yes, I have this in mind too.
> I have the same kind of ideas Christophe plus a few other (including a
> re
Hi Eric,
>First let me say that I have limited bandwidth at the moment, and apologize in
>advance for my short reply...
No need to apologize, I can understand this ;-)
>And what you need is for the type of the Proto expression generated by
>"(g1 || g2) && !g3" to be default-constructable? Have
>Calling phoenix expressions from the statement module return void.
>Calling phoenix expressions from any other modules return whatever ...
>depending on the "C++-Sense".
It's ok, I can live with it, though I'll need to find a way around
because I do need this return stuff.
>> If you allow a sho
On Monday, March 14, 2011 01:39:41 PM Christophe Henry wrote:
> Hi Thomas,
>
> >> Row < source_state , event , target_state, action , guard >
> >
> >I suggest you to look into spirit how semantic actions are dealt with, it
reminds me of exactly this:
> Ok I will, thanks.
Keep in mind, spirit use
On Sunday, March 13, 2011 10:07:30 PM Christophe Henry wrote:
> Hi all,
>
> I started a rewrite of a major part of my eUML front-end to fix the
> issues I left open in the current version, and I'm now at the point
> where I've done enough to present what I have and get some opinions on
> the choic
On 14/03/11 04:49, Eric Niebler wrote:
Exciting stuff! Truly Christophe, your ideas re decltype and EDSLs in
C++ are revolutionary. But unfortunately, I fear it will require a
revolution. This is all do-able, but the changes to MPL, Proto and even
to Phoenix in the case of the lambda capture stuf
Hi Christophe,
First let me say that I have limited bandwidth at the moment, and
apologize in advance for my short reply...
On 3/14/2011 4:07 AM, Christophe Henry wrote:
> Hi all,
>
> I started a rewrite of a major part of my eUML front-end to fix the
> issues I left open in the current version,
12 matches
Mail list logo
