Pretty much. Part of what the single_identifier action does is copy
yytext into a std::string, and then it's that std::string that I use
from then on.
Actually, just now I changed that IDENTIFIER inside the
field_declaration section to single_identifier, and now it works! Why
would that make
Are you strcpy'ing off the value of yytext before getting it from $3?
-Chris
On Mon, Mar 8, 2010 at 6:10 PM, Brad wrote:
> Doh, sorry about that. The extra single_identifier was left over from when
> I was trying to debug the problem. The original grammar that has the yytext
> issue didn't hav
Doh, sorry about that. The extra single_identifier was left over from
when I was trying to debug the problem. The original grammar that has
the yytext issue didn't have the extra single_identifier. Ignore it.
-Brad
Chris verBurg wrote:
Hey Brad,
Do you mean to have "single_identifier" listed
I ended up removing the offending paragraph completely – it really didn’t
add anything to the post and gave people the wrong impression about the
differences between the C skeleton and C++ skeleton. If you are playing with
tools like Flex and Bison you probably know enough to decide for yourself
wh
Here is a snippet from my grammer that parses a C++-like language.
field_declaration:
modifiers_opt type IDENTIFIER SEMICOLON
{
/* stuff */
}
;
method_header:
modifiers_opt type single_identifier single_identifier LPAREN RPAREN
{
/* stuff */
}
| modifiers_op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Hollencamp wrote:
> I made an example of using Flex and Bison together in C++ and was
> wondering if you guys could provide some feedback. Despite the C++
> interface being 'experimental' I found it works out pretty good
> after you figure it ou
Hi,
I definitely wouldn't say this:
"Edit: March 7 2010 [...] In C mode, the generated
code uses global variables to store information, making them
non-thread-safe. It is also a pain to create multiple different parsers
/ scanners and include them in the same program. Using C++ mode, all of
the
