On 7 Aug 2006, at 04:55, Dong Tiger wrote:
Actually, I am writing a code analyser which parses c/c++ code
without doing the preprocess thing. So when I encounter an
ambiguity, I just 'guess' which option is more proper.
Symbol table, when I have time to write it, will be helpful to
Actually, I am writing a code analyser which parses c/c++ code without
doing the preprocess thing. So when I encounter an ambiguity, I just 'guess'
which option is more proper.
Symbol table, when I have time to write it, will be helpful to make the
guess more accurate.
At this moment, %
On 4 Aug 2006, at 16:16, Sylvain Schmitz wrote:
Your lexer could lookup your symbol table and return TYPE in one
case and VAR in the other.
Unfortunately, C and C++ contains some ambiguities that cannot be
resolved that way.
Hans Aberg
___
Dong Tiger wrote:
Look at the following expression( c-like syntax):
1 - 2 * (TYPE_OR_VAR) - 1
The real token type of TYPE_OR_VAR is unknown. The expression could be
parsed as the following two options:
1. TYPE_OR_VAR is a typename. Then "(TYPE_OR_VAR)-1" is a cast expression.
And the exp
Your question is rather out of context, so it is hard to give an answer.
There is a Yacc-like grammar for C++, you might look at that one:
http://www.parashift.com/c++-faq-lite/compiler-
dependencies.html#faq-38.11
Otherwise, you might check out the Usenet newsgroup comp.compilers,
and its
Dong Tiger,
I would like to choose the second option but I can't do it with
"%dprec". As
when the ambiguity happens, the two options
are shifted by the same rule.
What can I do to get around this problem?
Use %merge
I had exactly the same problem with my C grammar and solved
it this way.
-
Look at the following expression( c-like syntax):
1 - 2 * (TYPE_OR_VAR) - 1
The real token type of TYPE_OR_VAR is unknown. The expression could be
parsed as the following two options:
1. TYPE_OR_VAR is a typename. Then "(TYPE_OR_VAR)-1" is a cast expression.
And the expression equals to:
