Re: yyerrok is missing in C++ parser

[kogorman]

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.

address@hidden clsix $ bison -d -ra -S lalr1.cc -o sixcl-parser.cc
sixcl-parser.yy
address@hidden 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
address@hidden clsix $ grep yyerrok *
sixcl-parser.cc:    { yyerrok; ;}
sixcl-parser.yy:    | error EOL { yyerrok; }
address@hidden 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.