How do I use C++ in flex and bison?
Solution 1
You don't need to do anything with flex or bison to use C++, I have done it many times. You just have to make sure you use g++, not gcc.
Your problems are with the Makefile, not the code.
Solution 2
For using flex with C++:
1: read the flex docs:
2: use flex -+ -o file.cc parser.ll
3: In the .ll file:
%option c++
%option yyclass="Your_class_name"
%option batch
4: In your .hh file, derive Your_class_name from public yyFlexLexer
5: you can then use your_class_instance.yylex()
Solution 3
There are some differences that you can check out in detail here.
Tom
I know and like C++, Java, and Python... although my work these days is all done in Java. I am a Computer Scientist... not a Programmer :-). I filled this out just so I could get the autobiographer badge :-P.
Updated on July 19, 2022Comments
-
Tom almost 2 years
I have a project for school where we need to use flex and bison. I want to use C++ so that I have access to STL and my own classes that I wrote. We were provided with the following Makefile:
CC = gcc CFLAGS = -g OBJs = parse.tab.o symtab.o attr.o lex.yy.o default: parser parser: ${OBJs} ${CC} ${CFLAGS} ${OBJs} -o parser -lfl lex.yy.c: scan.l parse.tab.h attr.h flex -i scan.l parse.tab.c: parse.y attr.h symtab.h bison -dv parse.y parse.tab.h: parse.tab.c clean: rm -f parser lex.yy.c *.o parse.tab.[ch] parse.output depend: makedepend -I. *.c
scan.l and parse.y have some initial flex/bison stuff to generate the scanner and parser. I need to add my own stuff to those files. symtab.{h, c} is supposed to be a implementation of a symbol table. attr.{h, c} are for some attribute magic. I want to make symtab.c a .cc file so I can use STL. I also have other reasons for wanting to use C++.
I tried to use a parse.ypp file, so that a .cpp file would be generated. But the problem is that I'm not getting the right .h file. I changed the Makefile to look like this:
CC = g++ # Change gcc to g++ CFLAGS = -g OBJs = lex.yy.o parse.tab.o symtab.o attr.o default: lex.yy.c parser # added lex.yy.c so I could just keep lex stuff in C since I don't really need C++ there parser: ${OBJs} ${CC} ${CFLAGS} ${OBJs} -o parser -lfl lex.yy.o: scan.l parse.tab.h attr.h # added this rule to use gcc instead of g++ gcc -c -o lex.yy.o lex.yy.c lex.yy.c: scan.l parse.tab.h attr.h flex -i scan.l parse.tab.cpp: parse.ypp attr.h symtab.h bison -dv parse.ypp parse.tab.h: parse.tab.cpp # I want a parse.tab.h but I get parse.tab.hpp clean: rm -f parser lex.yy.c *.o parse.tab.cpp parse.tab.h parse.output depend: makedepend -I. *.c
Can someone tell me what I need to add or do to get C++ working? It should be noted I added some stuff in the .y (or .ypp) file to deal with moving from C to C++. In particular, I had to declare some stuff as extern. My main problem is that when I run make, scan.l has a bunch of syntax errors, and they seem to be because it cannot include parse.tab.h (because it is never generated).
-
Venedictos about 15 yearsI disagree. I have tried both and I like bison better (although I prefer ANTLR over both). The weird syntax needed to fit EBNF into C++ makes it very hard to read grammars.
-
Scottie T about 15 yearsNot an option in this case, since he's required to use bison/flex for his project. Beside, not everything in C++ need be done with Boost.
-
Tom over 14 yearsAccepting this pretty late :-)... but as I recall this was right and I just needed to play around with my makefile. thanks.
-
Hippicoder almost 14 yearsSpirit is one of the worst and overly complicated C++ libraries out there. If anything its nothing more than a whimsical attempt at seeing what kind of operators one can overload in C++.
-
Kasper Peeters almost 14 yearsMoreover, Spirit is horribly unstable. Even the most trivial examples fail to compile from one version to the next, often just with a non-explanatory compiler error.
-
wjl almost 13 yearsThe other commenters dislike Spirit. I actually like Spirit quite a bit. It uses operator overloading quite reasonably and works as advertised. It is very nice for replacing ad-hoc parsing of small things like JSON, CSV, etc. However, having tried using it in earnest on a couple non-trivial projects, I have found it functional and performant, but somewhat tedious to use for more than small grammars.