Re: Problems using bison and flex with C++

[Laurence Finston]

On Thu, 24 Jun 2004, Hans Aberg wrote:

> At 09:29 +0200 2004/06/23, Laurence Finston wrote:
> >On Tue, 22 Jun 2004, Hans Aberg wrote:
> >> The Bison C parser will not work under C++ for several reasons, for
> >> example, its stack does not invoke copy constructors when re-allocating. As
> >> I could not get the Bison C++ parser working directly, I wrote my own. The
> >> details are posted in the Bison-Patches group. Some fellows said that they
> >> were able to follow the instructions to get a working C++ parser on their
> >> own. I think this is the state of the matter, until somebody writes a
> >> (working) C++ parser that comes with the Bison distribution.
> ...
> >I don't understand this. I'm using Bison with C++ and I haven't had any
> >problems. With very few exceptions valid C code should also be valid
> >C++ code.  Am I missing something here?
>
> You probably want me to repeat what I just wrote above:
>
> >> The Bison C parser will not work under C++ for several reasons, for
> >> example, its stack does not invoke copy constructors when re-allocating.
>
> So if your C++ parser class use non-trivial copy-constructors, and the C
> stacks are re-allocated, the new stuff on the new stack will be wrong. You
> will be safe if you do not feed an input segment that is so big that the
> C-stacks re-allocate, or if you only use POD on your parser stack (which
> must be the case if you use say the %union feature together with a
> compliant C++ compiler, as non-POD's will then be rejected).
>

I didn't understand Carlos' original query as implying that he was using a C++
parser class, although he might be.  For my application, I haven't had any
reason to use one.  Since my parser needs to be reentrant, I store information
and pass it to `yyparse()' via `YYPARSE_PARAM' anyway, so there doesn't seem to
me to be any point in storing information in the data members of a parser class,
too.  However, it might be useful in some circumstances.

I've been assuming that the parser stack is also local to `yyparse()' when
one generates a reentrant parser.  I've been planning to call `yyparse()'
multiple times in multiple threads to read multiple input files. I haven't tried
this out yet, and I've now rechecked the Bison manual, but haven't found
anything to support this assumption.  Could somebody tell me whether it's
correct?

Carlos, I don't understand why you can build your executable with gcc and not
with g++.  If you call gcc without the `-x c++' option, it will assume that
`parser.tab.c'
is C, so I would expect it not to compile, if it in fact contains C++.
I believe that the error messages are in fact from the linker rather than
the compiler, since they say that the functions are undefined rather than
undeclared.  Does the following work?  (It assumes you define `main()' in your
Bison input file.)

   g++ -c -o lexer.o lexer.tab.c
   g++ -c -o parser.o parser.tab.c
   g++ lexer.o parser.o

However, I wouldn't expect gcc to be able to find the function
definitions, either, if you're not linking the object files correctly.

Laurence


At 09:07 -0300 2004/06/22, Carlos Augusto Lains Leit=E3o wrote:
>       My name is Carlos and i am experiencing some problems using flex
>and bison with c++. I have generated the lexical scanner with flex and the
>the parser with bison. When i compile my program with gcc there is no
>problem and everything goes well but when i use g++ to compile the
>compiler points some errors such like: "undefined reference to yylex in
>the parser.tab.c generated by bison, undefined reference to yyparse in
>lex.yy.c generated by flex, undefined reference to yyerror in parser.tab.c
>generated by bison". Colud anyone give me an advice.