Re: [boost] [msm] eUML guard/action location
Are all those parentheses used for optional arguments, or could we consider eliminating them?
I'd love to eliminate them but don't see how. They actually are constructors. The complete expression would be something like: typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table; So I'm really just pretending to pass on-the-fly instances of arguments from types DestState, CurrentState, etc. to evaluate the result with typeof after proto is done.
On Mon, 2009-12-14 at 13:31 +0100, Christophe Henry wrote:
Are all those parentheses used for optional arguments, or could we consider eliminating them?
I'd love to eliminate them but don't see how. They actually are constructors. The complete expression would be something like:
typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table;
So I'm really just pretending to pass on-the-fly instances of arguments from types DestState, CurrentState, etc. to evaluate the result with typeof after proto is done.
Yes it is an interesting "hack".How "pretend" have you been able to make this? I was actually thinking about exactly this today (long drive - actually - correction - I was thinking about it yesterday - it's now early morning here) and wondering what the consequences were. Does it result in actually default constructing all these (temporary) objects? Won't that be expensive and/or have undesirable side effects?
At Mon, 14 Dec 2009 13:31:29 +0100, Christophe Henry wrote:
Are all those parentheses used for optional arguments, or could we consider eliminating them?
I'd love to eliminate them but don't see how. They actually are constructors. The complete expression would be something like:
typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table;
So I'm really just pretending to pass on-the-fly instances of arguments from types DestState, CurrentState, etc. to evaluate the result with typeof after proto is done.
You could declare those instances at namespace scope, in the same way most Proto terminals are declared, non? -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table;
You could declare those instances at namespace scope, in the same way most Proto terminals are declared, non?
As on as those types are POD, the proto trick can be used yes: CurrenState const current_ = {}; -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Sun, Jan 10, 2010 at 7:54 AM, joel falcou <joel.falcou@lri.fr> wrote:
David Abrahams wrote:
typedef BOOST_TYPEOF(build_stt(( DestState() = CurrentState() + cool_event()[guard()]/action(), DestState2() = CurrentState() + cool_event()[guard2()]/action2() ) ) ) transition_table;
You could declare those instances at namespace scope, in the same way most Proto terminals are declared, non?
As on as those types are POD, the proto trick can be used yes:
CurrenState const current_ = {};
The user could. But not the library writer AFAIU, since these state types are created by the user.
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Regards, -- Felipe Magno de Almeida
participants (5)
-
Christophe Henry -
Darryl Green -
David Abrahams -
Felipe Magno de Almeida -
joel falcou