[net.lang.c] C++ and YACC

david@ukma.UUCP (David Herron, NPR Lover) (02/03/86)

I'm wanting to learn C++.  As the language is geared towards large
projects what I have in mind is finally fixing up my BASIC interpretor.
(You may remember me posting it to mod.sources last summer).

As I know very little about parsing I will want to use a YACC grammar
spec for the parser.  But will YACC and C++ inter-operate properly?
Or would a new sort of "language hosting" need to be done for C++?
Has anybody done a parser using YACC and C++?

My "working design" at the moment has the grammar also recognizing
the normal user-level commands (i.e. RUN, LIST, etc).  It generates
code lists into an intermediate language, and calls a function to
interpret this intermediate language at appropriate times.  So I won't
have to call yyparse() lots of times (I couldn't figure that one
out when I tried a couple of years ago).  But I will need to be
using some code that's C to call code that's C++.  Or maybe I can
just compile the yacc output with C++ instead of C?

Any suggestions?
-- 
David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, soon, david@uky.csnet.

Experience is something you don't get until just after you need it.

ggs@ulysses.UUCP (Griff Smith) (02/03/86)

> Will YACC and C++ inter-operate properly?
> Or would a new sort of "language hosting" need to be done for C++?
> Has anybody done a parser using YACC and C++?
> 
> I won't
> have to call yyparse() lots of times (I couldn't figure that one
> out when I tried a couple of years ago).  But I will need to be
> using some code that's C to call code that's C++.  Or maybe I can
> just compile the yacc output with C++ instead of C?
> 
> Any suggestions?
> -- 
> David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, soon, david@uky.csnet.
> 
The output of YACC is compatible with C++.  The compiler grumbles a bit
about the sloppy function declarations, but there are no fatal errors.
Lex is a bit worse; the complaints from the compiler are a bit louder,
though still non-fatal.  I run the output of lex through a sed script
to clean up warnings plus a few self-inflicted problems.
-- 

Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		(201) 582-7736
Internet:	ggs@ulysses.uucp
UUCP:		ulysses!ggs  ( {allegra|ihnp4}!ulysses!ggs )

bs@alice.UucP (Bjarne Stroustrup) (02/03/86)

> From allegra!ulysses!burl!clyde!cbosgd!ukma!david Wed Dec 31 19:00:00 1969

Nice date!

> From: david@ukma.UUCP (David Herron, NPR Lover)
> Newsgroups: net.lang.c
> Subject: C++ and YACC (?)
> Posted: Sun Feb  2 21:30:06 1986
> Organization: U of Kentucky, Mathematical Sciences, Lexington KY

> I'm wanting to learn C++.  As the language is geared towards large
> projects what I have in mind is finally fixing up my BASIC interpretor.
> (You may remember me posting it to mod.sources last summer).

Actually, it is not bad for small projects either.

> As I know very little about parsing I will want to use a YACC grammar
> spec for the parser.  But will YACC and C++ inter-operate properly?
> Or would a new sort of "language hosting" need to be done for C++?
> Has anybody done a parser using YACC and C++?

Yes, that has been done several times. In particular, the C++ parser is done
using yacc. You can simply write the actions in C++, yacc doesn't really know
about C.

> My "working design" at the moment has the grammar also recognizing
> the normal user-level commands (i.e. RUN, LIST, etc).  It generates
> code lists into an intermediate language, and calls a function to
> interpret this intermediate language at appropriate times.  So I won't
> have to call yyparse() lots of times (I couldn't figure that one
> out when I tried a couple of years ago).  But I will need to be
> using some code that's C to call code that's C++.  Or maybe I can
> just compile the yacc output with C++ instead of C?

Exactly. Just feed y.tab.c to CC (the C++ compiler) instead of cc.

> Any suggestions?
> David Herron,  cbosgd!ukma!david, david@UKMA.BITNET, soon, david@uky.csnet.
> Experience is something you don't get until just after you need it.

	- Bjarne Stroustrup