Boost logo

Boost :

Subject: [boost] [Spirit/Qi] Sequential-or attribute access in semantic action
From: Adam Butcher (dev.lists_at_[hidden])
Date: 2009-12-04 04:23:12


I am having a bit trouble with the semantic action of a sequential-or
parser. Specifically my problem is with accessing the attribute of the
sequential-or parser. My first observation is that the documentation at
defines the attribute type of (a || b) as tuple<A, B>. Unless I've
misunderstood, this must be a typo as they should both be optional (it is
never valid for both to be omitted but I would expect that client code be
able to determine which out of (a), (b) or (a >> b) were provided.)

My real problem is that applying a semantic action to [what I think is] an
expression returning a sequential-or parser, results in the _1 referring
to the attribute of the last parser on the right-hand-side of the
sequential-or rather than the attribute of the sequential-or parser
itself. In the following snippet (assume 'start' has an attribute of type

      idxspec = '[' >> (start || (':' >> -start))
                    _val = access_index (_r1,lvalue,_1)
>> ']';

the function 'access_index' is called with an arg3 of type 'optional<S>'
rather than the expected 'tuple<optional<S>, optional<optional<S>>>'.

Wrapping the sequential-or expression in a 'repeat' directive as

   repeat(1)[start || (':' >> -start)]

solved the problem but obviously gave me an unwanted sequence (albeit with
only one element). The attribute type of the above came out to be

   vector<tuple<optional<S>, optional<optional<S>>>>

as expected.

To remove the sequence I created a parser directive called 'identity'
following the form of 'repeat' which I have attached. My final rule is

      idxspec = '[' >> identity[start || (':' >> -start)]
                    _val = access_index (_r1,lvalue,_1)
>> ']';

which is working fine; the _1 delivers an argument of type

   tuple<optional<S>, optional<optional<S>>>

as required. However, I would have expected this behaviour from the first
expression. Is this a a proto issue, a spirit issue or have I completely
misunderstood something somewhere?

It may or may not be relevant but I am using both spirit.classic and
spirit 2.1 in the same file. This is historical and will be fixed in time
but I guess it could be important. So far I have had no problems with the
combination however.

Additional info: I am using gcc 4.4.2, stlport 5.1.3 and boost 1.41.0.


Boost list run by bdawes at, gregod at, cpdaniel at, john at