Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The token attribute exposes a variant, which in addition to the base-iterator range, can _assume the types declared in the <code>token_type</code> typedef:</p> <pre><code>typedef lex::lexertl::token&lt;base_iterator_type, mpl::vector&lt;std::string, int, double&gt;&gt; token_type; </code></pre> <p>So: <code>string</code>, <code>int</code> and <code>double</code>. Note however that <em>coercion</em> into one of the possible types will only occur lazily, when the parser <em>actually</em> uses the value. </p> <p><code>utree</code>s are a very versatile container <strong><sup>[1]</sup></strong>. Hence, when you expose a <code>spirit::utree</code> attribute on a rule, and the token <em>value variant</em> contains an iterator_range, then it attempts to assign that into the <code>utree</code> object (this fails, because the iterators are ... 'funky'). </p> <p>The easiest way to get your desired behaviour is to <strong><em>force</em></strong> Qi to interpret the attribute of the <code>tag</code> token as a string, and have <em>that</em> assigned to the <code>utree</code>. Therefore the following line constitutes a fix that will make compilation succeed:</p> <pre><code> unknowntagvalue = qi::as_string[tok.tag] &gt;&gt; restofline; </code></pre> <h2>Notes</h2> <p>Having said all this, I would indeed suggest the following</p> <ul> <li><p>Consider using the <code>Nabialek Trick</code> to dispatch different <em>lazy rules</em> depending on the <code>tag</code> matched - this makes it unnecessary to deal with raw <code>utree</code>s later on</p></li> <li><p>You might have had success specializing <code>boost::spirit::traits::assign_to_XXXXXX</code> traits (see <a href="http://www.boost.org/doc/libs/1_53_0/libs/spirit/doc/html/spirit/advanced/customize/assign_to.html" rel="nofollow">documentation</a>)</p></li> <li><p>consider using a pure Qi parser. While I can "feel" your sentiment that "it is going to brittle" <strong><sup>[2]</sup></strong> it seems you have already demonstrated that it raises the complexity to such a degree that it might not have net merit:</p> <ul> <li>the unexpected ways in which attributes materialize (this question)</li> <li>the problem with line-pos iterators (this is frequently asked question, and AFAIR it has mostly <em>hard</em> or <em>inelegant</em> solutions)</li> <li>the inflexibility regarding e.g. ad-hoc debugging (access to source data in SA), switching/disabling skippers etc.</li> <li>my personal experience was that looking at <em>lexer states</em> to drive these isn't helpful, because switching lexer state can only work reliably from <code>lexer token semantic actions</code>, whereas often, the disambiguation would happen in the <em>Qi phase</em></li> </ul></li> </ul> <p>but I'm diverging :)</p> <hr> <p><strong><sup>[1]</sup></strong> e.g. they have facilities for very lightweight 'referencing' of iterator ranges (e.g. for symbols, or to avoid <em>copying characters</em> from a source buffer into the attribute unless wanted)</p> <p><strong><sup>[2]</sup></strong> In effect, only because using a sequential lexer (scanner) vastly reduces the number of backtrack opportunities, so it simplifies the mental model of the parser. However, you can use <code>expectation points</code> to much the same effect.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COFirstly, once again thank you sehe. Secondly, I had thought that utree stored its variants by storing iterator_range's (it's how I would have done it, it's the easiest route to variant storage in this case), and therefore could convert lazily. If utree doesn't do this - and by your answer I'm guessing it doesn't, then it looks like the Nabialek Trick is the only remaining. I had avoided it due to a lack of real world examples.
      singulars
    2. COBTW, I should explain why tokenisation. Callgrind output can easily break 100Mb of output. I also failed to get a pure Qi parser to completely grok MSVC's symbol mangling (https://github.com/ned14/NiallsCPP11Utilities/blob/master/SymbolManglerMSVC.cpp) because it turns out to **need** a multi-pass parse to premark nested template mangles much as you would brackets in expressions. Still tender from that failure, I worry callgrind needs the same. It's entirely possible I'm being insecure :)
      singulars
    3. CO(a) utree is able to store opaque interator_ranges (but that won't be of use as long as you actually use (adapted) input iterators for the input) (b) any grammar can be expressed using spirit along, since semantic actions make it "turing complete"; Also, note `pos/neg lookahead` (unary& and unary!). Granted, this might become slower in the face of a lot of backtracking, but I'd say the linebased grammar looks simple enough to avoid backtracking in all but the most exceptional cases...
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload