Laurence Finston wrote:
>
> On Mon, 11 Aug 2008, kogorman wrote:
>
>>
>> All this is true, but beside the point. What's missing is yyerrok, not
>> yyerror.
>
> This is what you wrote:
>
>> >> But my C++ parser
>> >> won't compile because (it says) yyerror was not declared in this
>> context.
>
Gleep -- that's what happens when I post at 2 AM. My bad.
But the fact remains that it's yyerrok that's missing.
Laurence Finston wrote:
>
> I found this in the file of C++ code generated by Bison:
>
> #define yyerrok (yyerrstatus = 0)
>
> Are you perhaps typing `yyerrorok' instead of `yyerrok'?
>
Nope, I grep for yyerrok on all files in the directory, and see only my own
code and
things directly generated from it. I do not see a #define or other
definiton.
[EMAIL PROTECTED] clsix $ bison -d -ra -S lalr1.cc -o sixcl-parser.cc
sixcl-parser.yy
[EMAIL PROTECTED] clsix $ g++ -I. -g -O2 -c -o sixcl-parser.o sixcl-parser.cc
sixcl-parser.yy: In member function ‘virtual int yy::sixcl_parser::parse()’:
sixcl-parser.yy:73: error: ‘yyerrok’ was not declared in this scope
make: *** [sixcl-parser.o] Error 1
[EMAIL PROTECTED] clsix $ grep yyerrok *
sixcl-parser.cc: { yyerrok; ;}
sixcl-parser.yy: | error EOL { yyerrok; }
[EMAIL PROTECTED] clsix $
Did you do this from the code I included, or some of your own? If the
latter, I wonder
what's different. On that note, my Bison is version 2.3, as distributed
with gentoo
Linux. What's yours?
Laurence Finston wrote:
>
>
>>
>> I'm using a C++ setup because I don't want to mix FILE* and C++ streams,
>> and just because it seems the Right Thing To Do (TM).
>
> Of course, you can avoid using objects of type `FILE' and pointers
> to them if you want, but I don't see any reason why one shouldn't
> use them and C++ streams in the same program and/or compilation
> units. `popen', for example, returns a `FILE*' and I don't know of
> any function from the C++ STL that does the same thing and returns
> a stream object instead. One might even have a reason to use
> file descriptors. Generating C++ parser or generating a C
> parser that contains C++ code is just a matter of taste, not
> a question of right or wrong.
>
>
> Laurence
>
>
Yes, it's a matter of taste. Partly. But consider: that does not change
the
fact that if everyone acted as you do there would be no need for a C++
version of Bison. Maybe that would be a good thing. Maybe not. But it's
out here, and I'm trying it and it's not working for me. The mailing list
seems like the first step to take before filing a bug. I like to do what
footwork I can for the developers.
Besides all that, I was considering a bison/flex project for my systems
programming courses this year and I want to be current about what works
and what doesn't before I start acting like an expert in front of a bunch
of bright undergrads.
Of course, I'll try just fudging in the #define you gave above, and see if
that works. If not, since activity is low here, and there's only one
respondent, I may well go back to a C version, but it seems a pity to me.
For the courses, I'll likely use yacc and lex/flex on a C project to avoid
the issue completely.
--
View this message in context:
http://www.nabble.com/yyerrok-is-missing-in-C%2B%2B-parser-tp18919947p18931794.html
Sent from the Gnu - Bison - Help mailing list archive at Nabble.com.
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
