beshers@sylvester.columbia.edu (Clifford Beshers) (03/18/87)
How well do yacc and lex work with C++? Are there major problems, minor kludges. Must yacc and lex be re-written in C++, and, if so, has this been done? Cliff Beshers Columbia University CS Department beshers@sylvester.columbia.edu
laurae@sfsup.UUCP (03/19/87)
In article <4475@columbia.UUCP>, beshers@sylvester.columbia.edu.UUCP writes: > > How well do yacc and lex work with C++? Are there major problems, minor > kludges. Must yacc and lex be re-written in C++, and, if so, has this been > done? > > Cliff Beshers > Columbia University CS Department > beshers@sylvester.columbia.edu Lex and yacc can be combined with C++ without any problem. (In fact it's done frequently.) The only restriction I can think of is that YYSTYPE (if defined as a union) can't contain class objects with constructors, since the behavior is undefined. --le
mikem@otc.UUCP (03/20/87)
In article <4475@columbia.UUCP>, beshers@sylvester.columbia.edu (Clifford Beshers) writes: > > How well do yacc and lex work with C++? Are there major problems, minor > kludges. Must yacc and lex be re-written in C++, and, if so, has this been > done? > The C++ translator itself uses yacc, albeit in a standard "C" way, more or less. The short story is that using yacc is possible, but using lex seems too hard as it stands. I had a go, but there was just too much c-specific code produced by lex that made C++ throw up. I've almost finshed doing something that uses yacc in a "C++" way. It involves techniques like the following: class SomeParser { // ...... yylex(); yyparse(); }; You then write SomeParser::yylex() manually, (or by some other means compatible with C++), and write the yacc grammar in the normal way UNDER THE ASSUMPTION that it's within class SomeParser (which is very convenient indeed for accessing things it needs to.) I.e: Your grammar file looks like: /* file.y */ %% /* usual stuff */ %% /* rules as usual, but using C++ code */ %% #include /* the file containing the definition of SomeParser::yylex() */ The makefile then should contain something like: file.o : file.c CC -c file.c file.c : y.tab.c sed -e 's/^yyparse\([^;]*\)$$/SomeParser::yyparse\1/' y.tab.c > file.c y.tab.c : file.y yacc file.y The sed subsitution may need slight modification depending on your version of yacc, and the composition of your file structure, but you get the idea... Because yyparse has been made into SomeParser::yyparse, when it calls yylex() it will actually call SomeParser::yylex(). With a slightly more sophisticated sed script it may even be possible to have multiple parsers operating in the one program. (Useful in cases where different sources of input have to be parsed in different ways at different times...) Mike Mowbray Systems Development Overseas Telecommunications Commission (Australia) UUCP: {seismo,mcvax}!otc.oz!mikem ACSnet: mikem@otc.oz
rose@.UUCP (04/04/87)
Clifford Beshers writes: >How well do yacc and lex work with C++? Are there major problems, minor >kludges. Must yacc and lex be re-written in C++, and, if so, has this been >done? We use both Yacc and Lex with C++. The Makefile is vanilla, except for a line which says "CC = CC". There is only one glitch, which you may not care about: If the YYSTYPE is a union of types which have constructors, you've got to change it to a struct, and probably give it an explicit member-wise operator=. (Reason: C++ supports guaranteed initialization. The flip side of this is that C++ will not trust the programmer with uninitialized objects [when the type has G.I.], and so there's no way to say "trust me, this union object contains a Foo, and the Bar of it can stay uninitialized." Yacc type-checks your use of the union, so it should be trust-worthy.) Making the union into a struct amounts to allocating separate stacks, one for each type. ---------------------------------------------------------- John R. Rose Thinking Machines Corporation 245 First St., Cambridge, MA 02142 (617) 876-1111 rose@think.arpa ihnp4!think!rose ---------------------------------------------------------- John R. Rose Thinking Machines Corporation 245 First St., Cambridge, MA 02142 (617) 876-1111 rose@think.arpa ihnp4!think!rose