|
Boost : |
Subject: Re: [boost] [spirit] semantic action for mismatches?
From: caustik (caustik_at_[hidden])
Date: 2011-01-08 17:11:44
Figured it out..
struct sharedMyClass : public shared_ptr<class MyClass>
{
sharedMyClass () : shared_ptr<MyClass> { }
sharedMyClass (class MyClass *pMyClass) :
shared_ptr<pae_concept>(pMyClass, MyClass::Release) { }
};
Then just have your rules use sharedMyClass as a synthesized attribute.
On Sat, Jan 8, 2011 at 1:36 PM, caustik <caustik_at_[hidden]> wrote:
> On Sat, Jan 8, 2011 at 10:16 AM, caustik <caustik_at_[hidden]> wrote:
>
>> On Sat, Jan 8, 2011 at 10:03 AM, Hartmut Kaiser <hartmut.kaiser_at_[hidden]
>> > wrote:
>>
>>> > > > I might give that a shot as I can't seem to get local variables to
>>> > > > solve my problem. I would expect these two commands to have the
>>> same
>>> > > > result (albeit unnecessarily assigning the _a variable, which just
>>> > > > gets tossed away anyway), but apparently they are not?
>>> > > >
>>> > > > r = p[_a = _1]
>>> > > > r = p
>>> > >
>>> > > Automatic attribute propagation from the rhs expression to the lhs
>>> > > rule is disabled as soon as semantic actions are involved. If you
>>> want
>>> > > to enforce attribute propagation anyways, write:
>>> > >
>>> > > rule<...> r;
>>> > > r %= p[...];
>>> > >
>>> > > If the rhs has no semantic actions attached, operator=() behaves
>>> > > exactly like operator%=().
>>> >
>>> > That does the trick. Apologies for the previous top-post. I've been out
>>> of
>>> > the mailing list game for a while now =)
>>> >
>>> > This style ended up working and I can finally move on to other things:
>>> >
>>> > r %= p1[_a = _1] >> ('*' | (eps[bind(&class::undo, &instance, _a)] >>
>>> > !eps))
>>> > >> p2
>>>
>>> FWIW, this should do the same, but simpler:
>>>
>>> r %= p1[_a = _1] >> ('*' | !eps[bind(&class::undo, &instance, _a)]) >>
>>> p2;
>>>
>>>
>> Ah, I was thinking that ! behaved like this:
>>
>> (!eps)[action]
>>
>> as opposed to this:
>>
>> !(eps[action])
>>
>>
> Now, suppose to avoid all this, you want to instead just have each rule
> return a shared_ptr e.g.:
>
> rule<Iterator, shared_ptr<MyClass>()> start;
>
> Except, you don't want to call "delete" on MyClass* but instead you want to
> call your custom cleanup function. So, is there a way to tell your rule what
> parameters to pass to it's synthesized attribute's constructor, so that they
> construct like this:
>
> shared_ptr<MyClass> synthAttr(ptr, myDeleter);
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk