How to eliminate left recursion in context-free grammar? - regex

How would I eliminate the left recursion in this CFG?
<RE> -> <RE>'|'<CONCAT> | <CONCAT>
<CONCAT> -> <CONCAT><KLEEN> | <KLEEN>
<KLEEN> -> <KLEEN>'*' | <ELEM>
<ELEM> -> 'a' | 'b' | 'c' | 'd' | '('<RE>')'

Have a look at the section on Removing Left Recursion on Wikipedia.
Theres an description of exactly how to do it, following of;
Moore, Robert C. (May 2000). "Removing Left Recursion from Context-Free Grammars" . 6th Applied Natural Language Processing Conference: 249–255. http://aclweb.org/anthology-new/A/A00/A00-2033.pdf .

Related

How do I select a substring using a regexp in robot framework

In the Robot Framework library called String, there are several keywords that allow us to use a regexp to manipulate a string, but these manipulations don't seem to include selecting a substring from a string.
To clarify, what I intend is to have a price, i.e. € 1234,00 from which I would like to select only the 4 primary digits, meaning I am left with 1234 (which I will convert to an int for use in validation calculations). I have a regexp which will allow me to do that, which is as follows:
(\d+)[\.\,]
If I use Remove String Using Regexp with this regexp I will be left with exactly what I tried to remove. If I use Get Lines Matching Regexp, I will get the entire line rather than just the result I wanted, and if I use Get Regexp Matches I will get the right result except it will be in a list, which I will then have to manipulate again so that doesn't seem optimal.
Did I simply miss the keyword that will allow me to do this or am I forced to write my own custom keyword that will let me do this? I am slightly amazed that this functionality doesn't seem to be available, as this is the first use case I would think of when I think of using a regexp with a string...
You can use the Evaluate keyword to run some python code.
For example:
| Using 'Evaluate' to find a pattern in a string
| | ${string}= | set variable | € 1234,00
| | ${result}= | evaluate | re.search(r'\\d+', '''${string}''').group(0) | re
| | should be equal as strings | ${result} | 1234
Starting with robot framework 2.9 there is a keyword named Get regexp matches, which returns a list of all matches.
For example:
| Using 'Get regexp matches' to find a pattern in a string
| | ${string}= | set variable | € 1234,00
| | ${matches}= | get regexp matches | ${string} | \\d+
| | should be equal as strings | ${matches[0]} | 1234

Converting a constructor name to string in OCaml

I have the following type definitions in my code:
type tag =
| Head
| Title
| Body
| H1
| P;;
type domtree =
| Empty
| Node of tag * string * domtree list;;
I need to print the tags along with the strings. But I couldn't find any way to convert the tag (the constructor names in the first type definition) into strings and concatenate them with the string part of the domtree. Is there any specific way to do this? Does OCaml provide a way to convert non-inbuilt types into strings? I found a similar question in here but I didn't quite understand it.
There is no such a facility built in OCaml and you will need to write yourself the conversion function tag_to_string : tag -> string.
It is easy to generate the body of this string automatically, for instance, use this sed one-liner:
sed -e 's/\| \(.*\)/| \1 -> "\1"/'
and paste your tag definition in its standard input. It yields
| Head -> "Head"
| Title -> "Title"
| Body -> "Body"
| H1 -> "H1"
| P;; -> "P;;"
and you just have to clean the ;;.
There is a lot of other solutions to define this boilerplate code, I also love to use Emacs macros for this.

Is C++ context-free or context-sensitive?

I often hear claims that C++ is a context-sensitive language. Take the following example:
a b(c);
Is this a variable definition or a function declaration? That depends on the meaning of the symbol c. If c is a variable, then a b(c); defines a variable named b of type a. It is directly initialized with c. But if c is a type, then a b(c); declares a function named b that takes a c and returns an a.
If you look up the definition of context-free languages, it will basically tell you that all grammar rules must have left-hand sides that consist of exactly one non-terminal symbol. Context-sensitive grammars, on the other hand, allow arbitrary strings of terminal and non-terminal symbols on the left-hand side.
Browsing through Appendix A of "The C++ Programming Language", I couldn't find a single grammar rule that had anything else besides a single non-terminal symbol on its left-hand side. That would imply that C++ is context-free. (Of course, every context-free language is also context-sensitive in the sense that the context-free languages form a subset of the context-sensitive languages, but that is not the point.)
So, is C++ context-free or context-sensitive?
Below is my (current) favorite demonstration of why parsing C++ is (probably) Turing-complete, since it shows a program which is syntactically correct if and only if a given integer is prime.
So I assert that C++ is neither context-free nor context-sensitive.
If you allow arbitrary symbol sequences on both sides of any production, you produce an Type-0 grammar ("unrestricted") in the Chomsky hierarchy, which is more powerful than a context-sensitive grammar; unrestricted grammars are Turing-complete. A context-sensitive (Type-1) grammar allows multiple symbols of context on the left hand side of a production, but the same context must appear on the right hand side of the production (hence the name "context-sensitive"). [1] Context-sensitive grammars are equivalent to linear-bounded Turing machines.
In the example program, the prime computation could be performed by a linear-bounded Turing machine, so it does not quite prove Turing equivalence, but the important part is that the parser needs to perform the computation in order to perform syntactic analysis. It could have been any computation expressible as a template instantiation and there is every reason to believe that C++ template instantiation is Turing-complete. See, for example, Todd L. Veldhuizen's 2003 paper.
Regardless, C++ can be parsed by a computer, so it could certainly be parsed by a Turing machine. Consequently, an unrestricted grammar could recognize it. Actually writing such a grammar would be impractical, which is why the standard doesn't try to do so. (See below.)
The issue with "ambiguity" of certain expressions is mostly a red herring. To start with, ambiguity is a feature of a particular grammar, not a language. Even if a language can be proven to have no unambiguous grammars, if it can be recognized by a context-free grammar, it's context-free. Similarly, if it cannot be recognized by a context-free grammar but it can be recognized by a context-sensitive grammar, it's context-sensitive. Ambiguity is not relevant.
But in any event, like line 21 (i.e. auto b = foo<IsPrime<234799>>::typen<1>();) in the program below, the expressions are not ambiguous at all; they are simply parsed differently depending on context. In the simplest expression of the issue, the syntactic category of certain identifiers is dependent on how they have been declared (types and functions, for example), which means that the formal language would have to recognize the fact that two arbitrary-length strings in the same program are identical (declaration and use). This can be modelled by the "copy" grammar, which is the grammar which recognizes two consecutive exact copies of the same word. It's easy to prove with the pumping lemma that this language is not context-free. A context-sensitive grammar for this language is possible, and a Type-0 grammar is provided in the answer to this question: https://math.stackexchange.com/questions/163830/context-sensitive-grammar-for-the-copy-language .
If one were to attempt to write a context-sensitive (or unrestricted) grammar to parse C++, it would quite possibly fill the universe with scribblings. Writing a Turing machine to parse C++ would be an equally impossible undertaking. Even writing a C++ program is difficult, and as far as I know none have been proven correct. This is why the standard does not attempt to provide a complete formal grammar, and why it chooses to write some of the parsing rules in technical English.
What looks like a formal grammar in the C++ standard is not the complete formal definition of the syntax of the C++ language. It's not even the complete formal definition of the language after preprocessing, which might be easier to formalize. (That wouldn't be the language, though: the C++ language as defined by the standard includes the preprocessor, and the operation of the preprocessor is described algorithmically since it would be extremely hard to describe in any grammatical formalism. It is in that section of the standard where lexical decomposition is described, including the rules where it must be applied more than once.)
The various grammars (two overlapping grammars for lexical analysis, one which takes place before preprocessing and the other, if necessary, afterwards, plus the "syntactic" grammar) are collected in Appendix A, with this important note (emphasis added):
This summary of C++ syntax is intended to be an aid to comprehension. It is not an exact statement of the language. In particular, the grammar described here accepts a superset of valid C++ constructs. Disambiguation rules (6.8, 7.1, 10.2) must be applied to distinguish expressions from declarations. Further, access control, ambiguity, and type rules must be used to weed out syntactically valid but meaningless constructs.
Finally, here's the promised program. Line 21 is syntactically correct if and only if the N in IsPrime<N> is prime. Otherwise, typen is an integer, not a template, so typen<1>() is parsed as (typen<1)>() which is syntactically incorrect because () is not a syntactically valid expression.
template<bool V> struct answer { answer(int) {} bool operator()(){return V;}};
template<bool no, bool yes, int f, int p> struct IsPrimeHelper
: IsPrimeHelper<p % f == 0, f * f >= p, f + 2, p> {};
template<bool yes, int f, int p> struct IsPrimeHelper<true, yes, f, p> { using type = answer<false>; };
template<int f, int p> struct IsPrimeHelper<false, true, f, p> { using type = answer<true>; };
template<int I> using IsPrime = typename IsPrimeHelper<!(I&1), false, 3, I>::type;
template<int I>
struct X { static const int i = I; int a[i]; };
template<typename A> struct foo;
template<>struct foo<answer<true>>{
template<int I> using typen = X<I>;
};
template<> struct foo<answer<false>>{
static const int typen = 0;
};
int main() {
auto b = foo<IsPrime<234799>>::typen<1>(); // Syntax error if not prime
return 0;
}
[1] To put it more technically, every production in a context-sensitive grammar must be of the form:
αAβ &rightarrow; αγβ
where A is a non-terminal and α, β are possibly empty sequences of grammar symbols, and γ is a non-empty sequence. (Grammar symbols may be either terminals or non-terminals).
This can be read as A &rightarrow; γ only in the context [α, β]. In a context-free (Type 2) grammar, α and β must be empty.
It turns out that you can also restrict grammars with the "monotonic" restriction, where every production must be of the form:
α &rightarrow; β where |α| ≥ |β| > 0 (|α| means "the length of α")
It's possible to prove that the set of languages recognized by monotonic grammars is exactly the same as the set of languages recognized by context-sensitive grammars, and it's often the case that it's easier to base proofs on monotonic grammars. Consequently, it's pretty common to see "context-sensitive" used as though it meant "monotonic".
First, you rightly observed there are no context sensitive rules in the grammar at the end of the C++ standard, so that grammar is context-free.
However, that grammar doesn't precisely describe the C++ language, because it produces non-C++ programs such as
int m() { m++; }
or
typedef static int int;
The C++ language defined as "the set of well-formed C++ programs" is not context-free (it's possible to show that merely demanding variables to be declared makes it so). Given you can theoretically write Turing-complete programs in templates and make a program ill-formed based on their result, it's not even context-sensitive.
Now, (ignorant) people (usually not language theorists, but parser designers) typically use "not context-free" in some of the following meanings
ambiguous
can't be parsed with Bison
not LL(k), LR(k), LALR(k) or whatever parser-defined language class they chose
The grammar at the back of the standard doesn't satisfy these categories (i.e. it is ambiguous, not LL(k)...) so C++ grammar is "not context-free" for them. And in a sense, they're right it's damn well hard to produce a working C++ parser.
Note that the properties here used are only weakly connected to context-free languages - ambiguity doesn't have anything to do with context-sensitivity (in fact, context-sensitive rules typically help disambiguate productions), the other two are merely subsets of context-free languages. And parsing context-free languages is not a linear process (although parsing deterministic ones is).
Yes. The following expression has a different order of operations depending on type resolved context:
Edit: When the actual order of operation varies, it makes it incredibly difficult to use a "regular" compiler that parses to an undecorated AST before decorating it (propagating type information). Other context sensitive things mentioned are "rather easy" compared to this (not that template evaluation is at all easy).
#if FIRST_MEANING
template<bool B>
class foo
{ };
#else
static const int foo = 0;
static const int bar = 15;
#endif
Followed by:
static int foobar( foo < 2 ? 1 < 1 : 0 > & bar );
To answer your question, you need to distinguish two different questions.
The mere syntax of almost every programming language is context-free. Typically, it is given as an extended Backus-Naur form or context-free gramar.
However, even if a program conforms with the context-free gramar defined by the programming language, it is not necessarily a valid program. There are many non-context-free poperties that a program has to satisfy in order to be a valid program. E.g., the most simple such property is the scope of variables.
To conclude, whether or not C++ is context-free depends on the question you ask.
You might want to take a look at The Design & Evolution of C++, by Bjarne Stroustrup. In it he describes his problems trying to use yacc (or similar) to parse an early version of C++, and wishing he had used recursive descent instead.
Yeah C++ is context sensitive, very context sensitive. You cannot build the syntax tree by simply parsing through the file using a context free parser because in some cases you need to know the symbol from previous knowledge to decide (ie. build a symbol table while parsing).
First example:
A*B;
Is this a multiplication expression?
OR
Is this a declaration of B variable to be a pointer of type A?
If A is a variable, then it's an expression, if A is type, it's a pointer declaration.
Second example:
A B(bar);
Is this a function prototype taking an argument of bar type?
OR
Is this declare variable B of type A and calls A's constructor with bar constant as an initializer?
You need to know again whether bar is a variable or a type from symbol table.
Third example:
class Foo
{
public:
void fn(){x*y;}
int x, y;
};
This is the case when building symbol table while parsing does not help because the declaration of x and y comes after the function definition. So you need to scan through the class definition first, and look at the method definitions in a second pass, to tell x*y is an expression, and not a pointer declaration or whatever.
I have a feeling that there's some confusion between the formal definition of "context-sensitive" and the informal use of "context-sensitive". The former has a well-defined meaning. The latter is used for saying "you need context in order to parse the input".
This is also asked here:
Context-sensitivity vs Ambiguity.
Here's a context-free grammar:
<a> ::= <b> | <c>
<b> ::= "x"
<c> ::= "x"
It's ambiguous, so in order to parse the input "x" you need some context (or live with the ambiguity, or emit "Warning: E8271 - Input is ambiguous in line 115"). But it's certainly not a context-sensitive grammar.
C++ is parsed with GLR parser. That means during parsing the source code, the parser may encounter ambiguity but it should continue and decide which grammar rule to use later.
look also,
Why C++ cannot be parsed with a LR(1) parser?
Remember that context-free grammar can not describe ALL the rules of a programming language syntax. For example, Attribute grammar is used to check the validity of an expression type.
int x;
x = 9 + 1.0;
You can not describe the following rule with context-free grammar :
The Right Side of the assignment should be of the same type of the Left Hand side.
No Algol-like language is context-free, because they have rules that constrain expressions and statements that identifiers can appear in based on their type, and because there's no limit on the number of statements that can occur between declaration and use.
The usual solution is to write a context-free parser that actually accepts a superset of valid programs and put the context-sensitive portions in ad hoc "semantic" code attached to rules.
C++ goes well beyond this, thanks to its Turing-complete template system. See Stack Overflow Question 794015.
True :)
J. Stanley Warford. Computer systems. Pages 341-346.
Sometimes it's worse: What do people mean when they say C++ has "undecidable grammar"?
It is context-sensitive, as a b(c); has two valid parses- declaration and variable. When you say "If c is a type", that's context, right there, and you've described exactly how C++ is sensitive to it. If you didn't have that context of "What is c?" you could not parse this unambiguously.
Here, the context is expressed in the choice of tokens- the parser reads an identifier as a typename token if it names a type. This is the simplest resolution, and avoids much of the complexity of being context-sensitive (in this case).
Edit: There are, of course, more issues of context sensitivity, I have merely focused on the one you've shown. Templates are especially nasty for this.
The productions in the C++ standard are written context-free, but as we all know don't really define the language precisely. Some of what most people see as ambiguity in the current language could (I believe) be resolved unambiguously with a context sensitive grammar.
For the most obvious example, let's consider the Most Vexing Parse: int f(X);. If X is a value, then this defines f as a variable that will be initialized with X. If X is a type, it defines f as a function taking a single parameter of type X.
Looking at that from a grammatical viewpoint, we could view it like this:
A variable_decl ::= <type> <identifier> '(' initializer ')' ';'
B function_decl ::= <type> <identifier> '(' param_decl ')' ';'
A ::= [declaration of X as value]
B ::= [declaration of X as type]
Of course, to be entirely correct we'd need to add some extra "stuff" to account for the possibility of intervening declarations of other types (i.e., A and B should both really be "declarations including declaration of X as...", or something on that order).
This is still rather different from a typical CSG though (or at least what I recall of them). This depends on a symbol table being constructed -- the part that specifically recognizes X as a type or value, not just some type of statement preceding this, but the correct type of statement for the right symbol/identifier.
As such, I'd have to do some looking to be sure, but my immediate guess is that this doesn't really qualify as a CSG, at least as the term is normally used.
The simplest case of non-context-free grammar involves parsing expressions involving templates.
a<b<c>()
This can parse as either
template
|
a < expr > ()
|
<
/ \
b c
Or
expr
|
<
/ \
a template
|
b < expr > ()
|
c
The two ASTs can only be disambiguated by examining the declaration of 'a' -- the former AST if 'a' is a template, or the latter if not.
C++ templates have been shown to be Turing Powerful. Although not a formal reference, here's a place to look in that regard:
http://cpptruths.blogspot.com/2005/11/c-templates-are-turing-complete.html
I will venture a guess (as old as a folkoric and concise CACM proof showing that ALGOL in the 60's could not be reprsented by a CFG) and say that C++ cannot therefore be correctly parsed only by a CFG. CFGs, in conjunction with various TP mechanisms in either a tree pass or during reduction events -- this is another story. In a general sense, due to the Halting Problem, there exists some C++ program that cannot be shown to be correct/incorrect but is nonetheless correct/incorrect.
{PS- As the author of Meta-S (mentioned by several people above) -- I can most assuredly say that Thothic is neither defunct, nor is the software available for free. Perhaps I have worded this version of my response such that I do not get deleted or voted down to -3.}
C++ is not context free. I learned it some time ago in compilers lecture. A quick search gave this link, where the "Syntax or semantics" section explains why C and C++ are not context free:
Wikipedia Talk: Context-Free grammar
Regards,
Ovanes
Obviously, if you take the question verbatim, nearly all languages with identifiers are context sensitive.
One need to know if an identifier is a type name (a class name, a name introduced by typedef, a typename template parameter), a template name or some other name to be able to correctly some of the use of identifier. For instance:
x = (name)(expression);
is a cast if name is a type name and a function call if name is a function name. Another case is the so called "most vexing parse" where it isn't possible to differentiate variable definition and function declaration (there is a rule saying it is a function declaration).
That difficulty has introduced the need of typename and template with dependent names. The rest of C++ isn't context sensitive as far as I know (i.e. it is possible to write a context free grammar for it).
Meta-S" is a context-sensitive parsing engine by Quinn Tyler Jackson. I've not used it, but he tells an impressive story. Check out his comments in comp.compilers, and see rnaparse.com/MetaS%20defined.htm – Ira Baxter Jul 25 at 10:42
The correct link is parsing enigines
Meta-S was the property of a defunct company called Thothic. I can send a free copy of the Meta-S to anyone interested and I've used it in rna parsing research. Please note the "pseudoknot grammar" included in the examples folders was written by an non-bioinformatics, amature programmer and basically doesn't work. My grammars take a different approach and work quite well.
A big issue here is that the terms "context-free" and "context-sensitive" are a little unintuitive within computer science. For C++, context-sensitivity looks a lot like ambiguity, but that's not necessarily true in the general case.
In C/++, an if statement is only allowed inside a function body. That would seem to make it context-sensitive, right? Well, no. Context-free grammars don't actually need the property where you can pluck out some line of code and determine whether it's valid. That's not actually what context-free means. It's really just a label that vaguely implies something kind of related to what it sounds like.
Now, if a statement within a function body is parsed differently depending on something defined outside immediate grammatical ancestors (e.g. whether an identifier describes a type or variable), as in the a * b; case, then it is, in fact, context-sensitive. There is no actual ambiguity here; it will be parsed as a declaration of a pointer if a is a type and a multiplication otherwise.
Being context-sensitive does not necessarily mean "hard to parse". C is actually not that hard because the infamous a * b; "ambiguity" can be resolved with a symbol table containing typedefs encountered previously. It doesn't require any arbitrary template instantiations (which have been proven to be Turing Complete) to resolve that case like C++ does on occasion. It's not actually possible to write a C program that will not compile in a finite amount of time even though it has the same context-sensitivity that C++ does.
Python (and other whitespace-sensitive languages) is also context-dependent, as it requires state in the lexer to generate indent and dedent tokens, but that doesn't make it any harder to parse than a typical LL-1 grammar. It actually uses a parser-generator, which is part of why Python has such uninformative syntax error messages. It's also important to note here that there is no "ambiguity" like the a * b; problem in Python, giving a good concrete example of a context-sensitive language without "ambiguous" grammar (as mentioned in the first paragraph).
This answer says C++ is not context-free... there's an implication (not by the answerer) that it can't be parsed, and the answer offers a difficult code example which produces an invalid C++ program if a certain constant is not a prime number.
As others have observed, the question about whether the language is context-sensitive/free is different than the same question about a specific grammar.
To set the question about parseability to rest, I offer empirical evidence that there are context-free grammars for C++, that can be used
to produce an AST for a context-free parse of the source text
by in fact parsing it with an existing GLR-parser-based tool that is driven by an explicit grammar.
Yes, it succeeds by "accepting too much"; not everything it accepts is a valid C++ program, which is why it's followed up with additional checks (type checks). And yes, the type checker may run into computability problems. In practice tools don't have this problem; if people wrote programs like that, none of them would compile. (I think the standard actually puts a limit on the amount of computation you can do unfolding a template, so in fact the computation is actually finite but probably pretty big).
If what you mean is, determine if the source program is a member
of the set of valid C++ source programs, then I will agree the
problem is a lot harder. But it isn't parsing that is the problem.
The tool resolves this issue by isolating parsing from type-checking
the parsed program. (Where there are multiple interpretations
in the absence of context, it records an ambiguity node
in the parse tree with several possible parses; the type
checking decides which one is correct and eliminates the invalid
subtrees). You can see a (partial) parse tree in the example below; the whole tree is too large to fit in an SO answer. Note you get a parse tree whether the value 234797 or 234799 is used.
Running the tool's name/type resolver over the AST with the original value 234799 succeeds. With the value 234797 the name resolver fails (as expected) with the error message, "typen is not a type." and thus that version is not a valid C++ program.
967 tree nodes in tree.
15 ambiguity nodes in tree.
(translation_unit#Cpp~GCC5=2#6b11a20^0 Line 1 Column 1 File C:/temp/prime_with_templates.cpp
(declaration_seq#Cpp~GCC5=1021#6b06640^1#6b11a20:1 {10} Line 1 Column 1 File C:/temp/prime_with_templates.cpp
(pp_declaration_seq#Cpp~GCC5=1022#6b049a0^1#6b06640:1 Line 1 Column 1 File C:/temp/prime_with_templates.cpp
(declaration#Cpp~GCC5=1036#6b04980^1#6b049a0:1 Line 1 Column 1 File C:/temp/prime_with_templates.cpp
|(template_declaration#Cpp~GCC5=2079#6b04960^1#6b04980:1 Line 1 Column 1 File C:/temp/prime_with_templates.cpp
| (template_parameter_list#Cpp~GCC5=2082#6afbde0^1#6b04960:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| (template_parameter#Cpp~GCC5=2085#6afbd80^1#6afbde0:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| (parameter_declaration#Cpp~GCC5=1611#6afbd40^1#6afbd80:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| |(basic_decl_specifier_seq#Cpp~GCC5=1070#6afb880^1#6afbd40:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| | (decl_specifier#Cpp~GCC5=1073#6afb840^1#6afb880:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| | (trailing_type_specifier#Cpp~GCC5=1118#6afb7e0^1#6afb840:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp
| | (simple_type_specifier#Cpp~GCC5=1138#6afb7a0^1#6afb7e0:1 Line 1 Column 10 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | )trailing_type_specifier#6afb7e0
| | )decl_specifier#6afb840
| |)basic_decl_specifier_seq#6afb880
| |(ptr_declarator#Cpp~GCC5=1417#6afbc40^1#6afbd40:2 Line 1 Column 15 File C:/temp/prime_with_templates.cpp
| | (noptr_declarator#Cpp~GCC5=1421#6afbba0^1#6afbc40:1 Line 1 Column 15 File C:/temp/prime_with_templates.cpp
| | (declarator_id#Cpp~GCC5=1487#6afbb80^1#6afbba0:1 Line 1 Column 15 File C:/temp/prime_with_templates.cpp
| | (id_expression#Cpp~GCC5=317#6afbaa0^1#6afbb80:1 Line 1 Column 15 File C:/temp/prime_with_templates.cpp
| | |(unqualified_id#Cpp~GCC5=319#6afb9c0^1#6afbaa0:1 Line 1 Column 15 File C:/temp/prime_with_templates.cpp
| | | (IDENTIFIER#Cpp~GCC5=3368#6afb780^1#6afb9c0:1[`V'] Line 1 Column 15 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | |)unqualified_id#6afb9c0
| | )id_expression#6afbaa0
| | )declarator_id#6afbb80
| | )noptr_declarator#6afbba0
| |)ptr_declarator#6afbc40
| )parameter_declaration#6afbd40
| )template_parameter#6afbd80
| )template_parameter_list#6afbde0
| (declaration#Cpp~GCC5=1033#6b04940^1#6b04960:2 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| (block_declaration#Cpp~GCC5=1050#6b04920^1#6b04940:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| (simple_declaration#Cpp~GCC5=1060#6b04900^1#6b04920:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| |(basic_decl_specifier_seq#Cpp~GCC5=1070#6b048e0^1#6b04900:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| | (decl_specifier#Cpp~GCC5=1073#6b048c0^1#6b048e0:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| | (type_specifier#Cpp~GCC5=1110#6b048a0^1#6b048c0:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| | (class_specifier#Cpp~GCC5=1761#6b04880^1#6b048a0:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| | |(class_head#Cpp~GCC5=1763#6afb980^1#6b04880:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp
| | | (class_key#Cpp~GCC5=1791#6afbca0^1#6afb980:1 Line 1 Column 18 File C:/temp/prime_with_templates.cpp)class_key
| | | (IDENTIFIER#Cpp~GCC5=3368#6afbcc0^1#6afb980:2[`answer'] Line 1 Column 25 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | (optional_base_clause#Cpp~GCC5=1872#6afba60^1#6afb980:3 Line 1 Column 32 File C:/temp/prime_with_templates.cpp)optional_base_clause
| | |)class_head#6afb980
| | |(member_specification#Cpp~GCC5=1794#6b042e0^1#6b04880:2 {2} Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | (member_declaration_or_access_specifier#Cpp~GCC5=1806#6b04060^1#6b042e0:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | (member_declaration#Cpp~GCC5=1822#6b04040^1#6b04060:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | (function_definition#Cpp~GCC5=1632#6b04020^1#6b04040:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | |(function_head#Cpp~GCC5=1673#6afbec0^1#6b04020:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | (ptr_declarator#Cpp~GCC5=1417#6afbfe0^1#6afbec0:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | (noptr_declarator#Cpp~GCC5=1422#6afbf80^1#6afbfe0:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | (noptr_declarator#Cpp~GCC5=1421#6afbf60^1#6afbf80:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | |(declarator_id#Cpp~GCC5=1487#6afbea0^1#6afbf60:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | | (id_expression#Cpp~GCC5=317#6afbb40^1#6afbea0:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | | (unqualified_id#Cpp~GCC5=319#6afbc80^1#6afbb40:1 Line 1 Column 34 File C:/temp/prime_with_templates.cpp
| | | | | (IDENTIFIER#Cpp~GCC5=3368#6afbc20^1#6afbc80:1[`answer'] Line 1 Column 34 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | | | )unqualified_id#6afbc80
| | | | | )id_expression#6afbb40
| | | | |)declarator_id#6afbea0
| | | | )noptr_declarator#6afbf60
| | | | (parameter_declaration_clause#Cpp~GCC5=1559#6afbd00^1#6afbf80:2 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | |(pp_parameter_declaration_list#Cpp~GCC5=1570#6afb940^1#6afbd00:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | (pp_parameter_declaration_seq#Cpp~GCC5=1574#6afb800^1#6afb940:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | (parameter_declaration#Cpp~GCC5=1610#6afb9a0^1#6afb800:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | (basic_decl_specifier_seq#Cpp~GCC5=1070#6afbf40^1#6afb9a0:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | |(decl_specifier#Cpp~GCC5=1073#6afbfa0^1#6afbf40:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | | (trailing_type_specifier#Cpp~GCC5=1118#6afbfc0^1#6afbfa0:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp
| | | | | | (simple_type_specifier#Cpp~GCC5=1140#6afb860^1#6afbfc0:1 Line 1 Column 41 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | | | | | )trailing_type_specifier#6afbfc0
| | | | | |)decl_specifier#6afbfa0
| | | | | )basic_decl_specifier_seq#6afbf40
| | | | | )parameter_declaration#6afb9a0
| | | | | )pp_parameter_declaration_seq#6afb800
| | | | |)pp_parameter_declaration_list#6afb940
| | | | )parameter_declaration_clause#6afbd00
| | | | (function_qualifiers#Cpp~GCC5=1438#6afbce0^1#6afbf80:3 Line 1 Column 46 File C:/temp/prime_with_templates.cpp)function_qualifiers
| | | | )noptr_declarator#6afbf80
| | | | )ptr_declarator#6afbfe0
| | | |)function_head#6afbec0
| | | |(function_body#Cpp~GCC5=1680#6b04000^1#6b04020:2 Line 1 Column 46 File C:/temp/prime_with_templates.cpp
| | | | (compound_statement#Cpp~GCC5=888#6afbee0^1#6b04000:1 Line 1 Column 46 File C:/temp/prime_with_templates.cpp)compound_statement
| | | |)function_body#6b04000
| | | )function_definition#6b04020
| | | )member_declaration#6b04040
| | | )member_declaration_or_access_specifier#6b04060
| | | (member_declaration_or_access_specifier#Cpp~GCC5=1806#6b042c0^1#6b042e0:2 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | (member_declaration#Cpp~GCC5=1822#6b04820^1#6b042c0:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | (function_definition#Cpp~GCC5=1632#6b04280^1#6b04820:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | |(function_head#Cpp~GCC5=1674#6b04220^1#6b04280:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | | (basic_decl_specifier_seq#Cpp~GCC5=1070#6b040e0^1#6b04220:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | | (decl_specifier#Cpp~GCC5=1073#6b040c0^1#6b040e0:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | | (trailing_type_specifier#Cpp~GCC5=1118#6b040a0^1#6b040c0:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp
| | | | |(simple_type_specifier#Cpp~GCC5=1138#6b04080^1#6b040a0:1 Line 1 Column 49 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | | | )trailing_type_specifier#6b040a0
| | | | )decl_specifier#6b040c0
| | | | )basic_decl_specifier_seq#6b040e0
| | | | (ptr_declarator#Cpp~GCC5=1417#6b04200^1#6b04220:2 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | (noptr_declarator#Cpp~GCC5=1422#6b041e0^1#6b04200:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | (noptr_declarator#Cpp~GCC5=1421#6b041a0^1#6b041e0:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | |(declarator_id#Cpp~GCC5=1487#6b04180^1#6b041a0:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | | (id_expression#Cpp~GCC5=317#6b04160^1#6b04180:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | | (unqualified_id#Cpp~GCC5=320#6b04140^1#6b04160:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | | (operator_function_id#Cpp~GCC5=2027#6b04120^1#6b04140:1 Line 1 Column 54 File C:/temp/prime_with_templates.cpp
| | | | | |(operator#Cpp~GCC5=2070#6b04100^1#6b04120:1 Line 1 Column 62 File C:/temp/prime_with_templates.cpp)operator
| | | | | )operator_function_id#6b04120
| | | | | )unqualified_id#6b04140
| | | | | )id_expression#6b04160
| | | | |)declarator_id#6b04180
| | | | )noptr_declarator#6b041a0
| | | | (parameter_declaration_clause#Cpp~GCC5=1558#6afba40^1#6b041e0:2 Line 1 Column 65 File C:/temp/prime_with_templates.cpp)parameter_declaration_clause
| | | | (function_qualifiers#Cpp~GCC5=1438#6b041c0^1#6b041e0:3 Line 1 Column 66 File C:/temp/prime_with_templates.cpp)function_qualifiers
| | | | )noptr_declarator#6b041e0
| | | | )ptr_declarator#6b04200
| | | |)function_head#6b04220
| | | |(function_body#Cpp~GCC5=1680#6b04300^1#6b04280:2 Line 1 Column 66 File C:/temp/prime_with_templates.cpp
| | | | (compound_statement#Cpp~GCC5=889#6b04760^1#6b04300:1 Line 1 Column 66 File C:/temp/prime_with_templates.cpp
| | | | (pp_statement_seq#Cpp~GCC5=894#6b04780^1#6b04760:1 Line 1 Column 67 File C:/temp/prime_with_templates.cpp
| | | | (statement#Cpp~GCC5=857#6b04440^1#6b04780:1 Line 1 Column 67 File C:/temp/prime_with_templates.cpp
| | | | |(jump_statement#Cpp~GCC5=1011#6afba80^1#6b04440:1 Line 1 Column 67 File C:/temp/prime_with_templates.cpp
| | | | | (pm_expression#Cpp~GCC5=551#6b04380^1#6afba80:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | (cast_expression#Cpp~GCC5=543#6b04360^1#6b04380:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | (unary_expression#Cpp~GCC5=465#6b04340^1#6b04360:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | |(primary_expression#Cpp~GCC5=307#6b04320^1#6b04340:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | | (id_expression#Cpp~GCC5=317#6b042a0^1#6b04320:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | | (unqualified_id#Cpp~GCC5=319#6b04260^1#6b042a0:1 Line 1 Column 74 File C:/temp/prime_with_templates.cpp
| | | | | | (IDENTIFIER#Cpp~GCC5=3368#6b04240^1#6b04260:1[`V'] Line 1 Column 74 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | | | | )unqualified_id#6b04260
| | | | | | )id_expression#6b042a0
| | | | | |)primary_expression#6b04320
| | | | | )unary_expression#6b04340
| | | | | )cast_expression#6b04360
| | | | | )pm_expression#6b04380
| | | | |)jump_statement#6afba80
| | | | )statement#6b04440
| | | | )pp_statement_seq#6b04780
| | | | )compound_statement#6b04760
| | | |)function_body#6b04300
| | | )function_definition#6b04280
| | | )member_declaration#6b04820
| | | )member_declaration_or_access_specifier#6b042c0
| | |)member_specification#6b042e0
| | )class_specifier#6b04880
| | )type_specifier#6b048a0
| | )decl_specifier#6b048c0
| |)basic_decl_specifier_seq#6b048e0
| )simple_declaration#6b04900
| )block_declaration#6b04920
| )declaration#6b04940
|)template_declaration#6b04960
)declaration#6b04980
)pp_declaration_seq#6b049a0
(pp_declaration_seq#Cpp~GCC5=1022#6b06620^1#6b06640:2 Line 3 Column 1 File C:/temp/prime_with_templates.cpp
(declaration#Cpp~GCC5=1036#6b06600^1#6b06620:1 Line 3 Column 1 File C:/temp/prime_with_templates.cpp
|(template_declaration#Cpp~GCC5=2079#6b065e0^1#6b06600:1 Line 3 Column 1 File C:/temp/prime_with_templates.cpp
| (template_parameter_list#Cpp~GCC5=2083#6b05460^1#6b065e0:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| (template_parameter_list#Cpp~GCC5=2083#6b05140^1#6b05460:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| (template_parameter_list#Cpp~GCC5=2083#6b04ee0^1#6b05140:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| |(template_parameter_list#Cpp~GCC5=2082#6b04cc0^1#6b04ee0:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | (template_parameter#Cpp~GCC5=2085#6b04ca0^1#6b04cc0:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | (parameter_declaration#Cpp~GCC5=1611#6b04c80^1#6b04ca0:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | (basic_decl_specifier_seq#Cpp~GCC5=1070#6b04a40^1#6b04c80:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | |(decl_specifier#Cpp~GCC5=1073#6b04a20^1#6b04a40:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | | (trailing_type_specifier#Cpp~GCC5=1118#6b04a00^1#6b04a20:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp
| | | (simple_type_specifier#Cpp~GCC5=1138#6b049e0^1#6b04a00:1 Line 3 Column 10 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | | )trailing_type_specifier#6b04a00
| | |)decl_specifier#6b04a20
| | )basic_decl_specifier_seq#6b04a40
| | (ptr_declarator#Cpp~GCC5=1417#6b04c40^1#6b04c80:2 Line 3 Column 15 File C:/temp/prime_with_templates.cpp
| | |(noptr_declarator#Cpp~GCC5=1421#6b04be0^1#6b04c40:1 Line 3 Column 15 File C:/temp/prime_with_templates.cpp
| | | (declarator_id#Cpp~GCC5=1487#6b04bc0^1#6b04be0:1 Line 3 Column 15 File C:/temp/prime_with_templates.cpp
| | | (id_expression#Cpp~GCC5=317#6b04b60^1#6b04bc0:1 Line 3 Column 15 File C:/temp/prime_with_templates.cpp
| | | (unqualified_id#Cpp~GCC5=319#6b04ac0^1#6b04b60:1 Line 3 Column 15 File C:/temp/prime_with_templates.cpp
| | | |(IDENTIFIER#Cpp~GCC5=3368#6b049c0^1#6b04ac0:1[`no'] Line 3 Column 15 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | )unqualified_id#6b04ac0
| | | )id_expression#6b04b60
| | | )declarator_id#6b04bc0
| | |)noptr_declarator#6b04be0
| | )ptr_declarator#6b04c40
| | )parameter_declaration#6b04c80
| | )template_parameter#6b04ca0
| |)template_parameter_list#6b04cc0
| |(template_parameter#Cpp~GCC5=2085#6b04ec0^1#6b04ee0:2 Line 3 Column 19 File C:/temp/prime_with_templates.cpp
| | (parameter_declaration#Cpp~GCC5=1611#6b04ea0^1#6b04ec0:1 Line 3 Column 19 File C:/temp/prime_with_templates.cpp
| | (basic_decl_specifier_seq#Cpp~GCC5=1070#6b04b40^1#6b04ea0:1 Line 3 Column 19 File C:/temp/prime_with_templates.cpp
| | (decl_specifier#Cpp~GCC5=1073#6b04ba0^1#6b04b40:1 Line 3 Column 19 File C:/temp/prime_with_templates.cpp
| | |(trailing_type_specifier#Cpp~GCC5=1118#6b04c60^1#6b04ba0:1 Line 3 Column 19 File C:/temp/prime_with_templates.cpp
| | | (simple_type_specifier#Cpp~GCC5=1138#6b04580^1#6b04c60:1 Line 3 Column 19 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | |)trailing_type_specifier#6b04c60
| | )decl_specifier#6b04ba0
| | )basic_decl_specifier_seq#6b04b40
| | (ptr_declarator#Cpp~GCC5=1417#6b04e60^1#6b04ea0:2 Line 3 Column 24 File C:/temp/prime_with_templates.cpp
| | (noptr_declarator#Cpp~GCC5=1421#6b04e40^1#6b04e60:1 Line 3 Column 24 File C:/temp/prime_with_templates.cpp
| | |(declarator_id#Cpp~GCC5=1487#6b04de0^1#6b04e40:1 Line 3 Column 24 File C:/temp/prime_with_templates.cpp
| | | (id_expression#Cpp~GCC5=317#6b04d80^1#6b04de0:1 Line 3 Column 24 File C:/temp/prime_with_templates.cpp
| | | (unqualified_id#Cpp~GCC5=319#6b04ce0^1#6b04d80:1 Line 3 Column 24 File C:/temp/prime_with_templates.cpp
| | | (IDENTIFIER#Cpp~GCC5=3368#6b04560^1#6b04ce0:1[`yes'] Line 3 Column 24 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | )unqualified_id#6b04ce0
| | | )id_expression#6b04d80
| | |)declarator_id#6b04de0
| | )noptr_declarator#6b04e40
| | )ptr_declarator#6b04e60
| | )parameter_declaration#6b04ea0
| |)template_parameter#6b04ec0
| )template_parameter_list#6b04ee0
| (template_parameter#Cpp~GCC5=2085#6b05120^1#6b05140:2 Line 3 Column 29 File C:/temp/prime_with_templates.cpp
| |(parameter_declaration#Cpp~GCC5=1611#6b05100^1#6b05120:1 Line 3 Column 29 File C:/temp/prime_with_templates.cpp
| | (basic_decl_specifier_seq#Cpp~GCC5=1070#6b04d20^1#6b05100:1 Line 3 Column 29 File C:/temp/prime_with_templates.cpp
| | (decl_specifier#Cpp~GCC5=1073#6b04dc0^1#6b04d20:1 Line 3 Column 29 File C:/temp/prime_with_templates.cpp
| | (trailing_type_specifier#Cpp~GCC5=1118#6b04e80^1#6b04dc0:1 Line 3 Column 29 File C:/temp/prime_with_templates.cpp
| | |(simple_type_specifier#Cpp~GCC5=1140#6b046e0^1#6b04e80:1 Line 3 Column 29 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | )trailing_type_specifier#6b04e80
| | )decl_specifier#6b04dc0
| | )basic_decl_specifier_seq#6b04d20
| | (ptr_declarator#Cpp~GCC5=1417#6b05080^1#6b05100:2 Line 3 Column 33 File C:/temp/prime_with_templates.cpp
| | (noptr_declarator#Cpp~GCC5=1421#6b05020^1#6b05080:1 Line 3 Column 33 File C:/temp/prime_with_templates.cpp
| | (declarator_id#Cpp~GCC5=1487#6b05000^1#6b05020:1 Line 3 Column 33 File C:/temp/prime_with_templates.cpp
| | |(id_expression#Cpp~GCC5=317#6b04fa0^1#6b05000:1 Line 3 Column 33 File C:/temp/prime_with_templates.cpp
| | | (unqualified_id#Cpp~GCC5=319#6b04f00^1#6b04fa0:1 Line 3 Column 33 File C:/temp/prime_with_templates.cpp
| | | (IDENTIFIER#Cpp~GCC5=3368#6b046c0^1#6b04f00:1[`f'] Line 3 Column 33 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | | )unqualified_id#6b04f00
| | |)id_expression#6b04fa0
| | )declarator_id#6b05000
| | )noptr_declarator#6b05020
| | )ptr_declarator#6b05080
| |)parameter_declaration#6b05100
| )template_parameter#6b05120
| )template_parameter_list#6b05140
| (template_parameter#Cpp~GCC5=2085#6b05440^1#6b05460:2 Line 3 Column 36 File C:/temp/prime_with_templates.cpp
| (parameter_declaration#Cpp~GCC5=1611#6b05420^1#6b05440:1 Line 3 Column 36 File C:/temp/prime_with_templates.cpp
| |(basic_decl_specifier_seq#Cpp~GCC5=1070#6b05160^1#6b05420:1 Line 3 Column 36 File C:/temp/prime_with_templates.cpp
| | (decl_specifier#Cpp~GCC5=1073#6b04fe0^1#6b05160:1 Line 3 Column 36 File C:/temp/prime_with_templates.cpp
| | (trailing_type_specifier#Cpp~GCC5=1118#6b050e0^1#6b04fe0:1 Line 3 Column 36 File C:/temp/prime_with_templates.cpp
| | (simple_type_specifier#Cpp~GCC5=1140#6b050c0^1#6b050e0:1 Line 3 Column 36 File C:/temp/prime_with_templates.cpp)simple_type_specifier
| | )trailing_type_specifier#6b050e0
| | )decl_specifier#6b04fe0
| |)basic_decl_specifier_seq#6b05160
| |(ptr_declarator#Cpp~GCC5=1417#6b053e0^1#6b05420:2 Line 3 Column 40 File C:/temp/prime_with_templates.cpp
| | (noptr_declarator#Cpp~GCC5=1421#6b053c0^1#6b053e0:1 Line 3 Column 40 File C:/temp/prime_with_templates.cpp
| | (declarator_id#Cpp~GCC5=1487#6b05360^1#6b053c0:1 Line 3 Column 40 File C:/temp/prime_with_templates.cpp
| | (id_expression#Cpp~GCC5=317#6b05280^1#6b05360:1 Line 3 Column 40 File C:/temp/prime_with_templates.cpp
| | |(unqualified_id#Cpp~GCC5=319#6b051a0^1#6b05280:1 Line 3 Column 40 File C:/temp/prime_with_templates.cpp
| | | (IDENTIFIER#Cpp~GCC5=3368#6b046a0^1#6b051a0:1[`p'] Line 3 Column 40 File C:/temp/prime_with_templates.cpp)IDENTIFIER
| | |)unqualified_id#6b051a0
| | )id_expression#6b05280
| | )declarator_id#6b05360
| | )noptr_declarator#6b053c0
| |)ptr_declarator#6b053e0
| )parameter_declaration#6b05420
| )template_parameter#6b05440
| )template_parameter_list#6b05460

(f)lex can you have multiple expressions in one state?

is it possible to have multiple expression in one state that are similar? I was hoping to group together a few expressions to make life easy for myself. i want to do something similar below but its not working and only recognise the 1st expr and although it does match the expr it doesnt save into the array using yytext. im guessing im doing something wrong so any help would be appreciated.Thanks
<some_state>"Milk;" |
"Honey;" |
"Cinnamon;" |
"Cardamon;" |
"Rum;" |
"Brandy;" |
"Whiskey;" |
"Aquavit;" |
"Kahula;" { printf("Example"); array[i].addition = yytext;BEGIN(amount_state);}
If flex is allowed, you can use start condition scope like the following:
<some_state>{
"Milk;" |
"Honey;" |
... |
"Kahula;" { printf("Example"); ... }
}
If only AT&T lex is allowed, unfortunately this may be invalid...

Unix: replace every odd | with \left| and every even | with \right|

An enormous equation. You need to add \left| on the left side of corresponding |. The corresponding | you need to replace with \right|.
Equation
\begin{equation}
| \Delta w_{0} | = \frac{|w_{0}|}{2} \left( |\frac{\Delta g}{g}|+|\frac{\Delta (\Delta r)}{\Delta r}| + |\frac{\Delta r}{r}| +|\frac{\Delta L}{L}| \right)
\end{equation}
[Premises]
The amount of | is even.
No nesting. So scenario such as M_OPEN|----X_OPEN|-----X_CLOSED|------M_CLOSED| is not possible, just M_OPEN|---M_CLOSED|---H_OPEN|----H_CLOSED|.
sed -r -e 's/\|([^|]+)\|/\\left|\1\\right|/g'
But this works only if you do not have nested |...|.