|
Boost : |
Subject: Re: [boost] [spirit] semantic action for mismatches?
From: caustik (caustik_at_[hidden])
Date: 2011-01-08 16:36:48
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