Topic: YACC and LEX for C++ ?


Author: hendrik@vedge.com (Hendrik Boom)
Date: Mon, 13 Sep 1993 22:13:49 GMT
Raw View
tkacik@adtaz.sps.mot.com (Tom Tkacik) writes:
: In article 17204@vedge.com, hendrik@vedge.com (Hendrik Boom) writes:
: >USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
: >: In article <1993Sep2.131346.23278@newsserver.rrzn.uni-hannover.de>
: >: stohmann@imes.uni-hannover.dbp.de (Joern Stohmann) writes:
: >: >Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
: >: >or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?
:
: >: Why don   t you use lex & yacc? I   m writing on a grammar-parser (a parser, which
: >: converts any given grammarfile into a c++-class-hierarchiy and a new grammar,
: >: which puts the parsed grammar objects back on the parser stack instead of
: >: int-values). Of course, after yacc-ing, I got plain C-code. But nobody stops
: >: me from calling c++-objects or -methods within the action-routines in my
: >: lex-file.
: >
: >Except that something does.  You are not allowed to place a class object
: >that has a constructor in a union.  The items on the yacc parse stack
: >are unions, so this severely restricts allowable use of C++.
:
: Yacc does not require that the items on its parse stack be unions.  That is common
: because there is not much else to do with C.  Yacc uses a #define to identify
: the type you want the stack to be.  It actually defaults to int.

No. it doesn't.  But it does support automatically corellating a
union selector with each nonterminal, providing an automatic type-check
that you are using the proper types of $ objects.  This strongly
encourages the use of unions.

:
: When using yacc with C++ I typically use "#define YYSTYPE Node*".
: Node is a base class.  Other derived classes can be used to get all of the
: needed types (that would normally be inside yacc's union).

But that leaves you with the downcasting problem, and loses you static
type-checking of information associated with nonterminals.

If it were to provide some other type-safe union mechanism
that accomplishes the same thing, I would be delighted.

--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik




Author: hendrik@vedge.com (Hendrik Boom)
Date: Mon, 13 Sep 1993 22:09:30 GMT
Raw View
leech@cs.unc.edu (Jon Leech) writes:
: In article <1993Sep07.200211.17204@vedge.com>, hendrik@vedge.com (Hendrik Boom) writes:
: |> USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
: |> : But nobody stops
: |> : me from calling c++-objects or -methods within the action-routines in my
: |> : lex-file.
: |>
: |> Except that something does. You are not allowed to place a class object
: |> that has a constructor in a union.  The items on the yacc parse stack
: |> are unions, so this severely restricts allowable use of C++.
:
:     Then you can use pointers. Parsers frequently want to dynamically
: allocate nodes anyway.

Right. Then you have to give up on smart pointers, and will have to
do reference-counting manually.  Better than using C, I suppose,
but still problematic.

 hendrik.
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik




Author: kanze@us-es.sel.de (James Kanze)
Date: 15 Sep 93 15:11:18
Raw View
In article <1993Sep13.221349.764@vedge.com> hendrik@vedge.com (Hendrik
Boom) writes:

|> tkacik@adtaz.sps.mot.com (Tom Tkacik) writes:
|> : In article 17204@vedge.com, hendrik@vedge.com (Hendrik Boom) writes:
|> : >USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
|> : >: In article <1993Sep2.131346.23278@newsserver.rrzn.uni-hannover.de>
|> : >: stohmann@imes.uni-hannover.dbp.de (Joern Stohmann) writes:
|> : >: >Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
|> : >: >or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?

|> : >: Why don   t you use lex & yacc? I   m writing on a grammar-parser (a parser, which
|> : >: converts any given grammarfile into a c++-class-hierarchiy and a new grammar,
|> : >: which puts the parsed grammar objects back on the parser stack instead of
|> : >: int-values). Of course, after yacc-ing, I got plain C-code. But nobody stops
|> : >: me from calling c++-objects or -methods within the action-routines in my
|> : >: lex-file.

|> : >Except that something does.  You are not allowed to place a class object
|> : >that has a constructor in a union.  The items on the yacc parse stack
|> : >are unions, so this severely restricts allowable use of C++.
|> :
|> : Yacc does not require that the items on its parse stack be unions.  That is common
|> : because there is not much else to do with C.  Yacc uses a #define to identify
|> : the type you want the stack to be.  It actually defaults to int.

|> No. it doesn't.  But it does support automatically corellating a
|> union selector with each nonterminal, providing an automatic type-check
|> that you are using the proper types of $ objects.  This strongly
|> encourages the use of unions.

|> : When using yacc with C++ I typically use "#define YYSTYPE Node*".
|> : Node is a base class.  Other derived classes can be used to get all of the
|> : needed types (that would normally be inside yacc's union).

|> But that leaves you with the downcasting problem, and loses you static
|> type-checking of information associated with nonterminals.

|> If it were to provide some other type-safe union mechanism
|> that accomplishes the same thing, I would be delighted.

I usually use a union of different types of pointers.

But this is actually less typesafe than using the Node*, and having
everything derive from it.  With Node*, you could at least potentially
implement your own RTTI, and get run time type checking.  (I know that
this is not in the philosophy of C++, but when the alternative is *no*
type checking...)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung




Author: andy@adfc.demon.co.uk (Andy Farlie)
Date: Sat, 11 Sep 1993 22:18:32 +0000
Raw View
In article <KANZE.93Sep8144746@slsvhdt.us-es.sel.de> kanze@us-es.sel.de writes:

>In article <1993Sep8.014224.5125@newsgate.sps.mot.com>
>tkacik@adtaz.sps.mot.com (Tom Tkacik) writes:
>
>|> The real problem is getting yacc to produce code that can be compiled with a
>|> C++ compiler.  I use byacc, and modified the skeleton to be C++ compatible.
>|> Flex seems to do ok out of the box.
>
>If you can modify the skeleton, yacc will produce C++ compatible code.
>If you cannot, it is still possible to pass the yacc output through a
>shell script (typically just 'sed') to modify the generated code.  (I
>you are willing to accept a few warnings, this is typically not too
>difficult.)
>--
>James Kanze                             email: kanze@us-es.sel.de
>GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
>Conseils en informatique industrielle --
>                   -- Beratung in industrieller Datenverarbeitung
>

I've got a copy of BISON that generates the parser (yyparse) within a
class so that you can run multiple parsers. I haven't used it excessively
yet but it appears to do the job. It's called bisonpp and I think it came
from Dr Dobbs Journal and was downloaded from CompuServe ('cos I wasn't on
the net at the time :-( ). I think that DDJ have a Net address from which
you can get the source.

--
Andy Farlie




Author: leech@cs.unc.edu (Jon Leech)
Date: 8 Sep 1993 00:27:08 GMT
Raw View
In article <1993Sep07.200211.17204@vedge.com>, hendrik@vedge.com (Hendrik Boom) writes:
|> USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
|> : But nobody stops
|> : me from calling c++-objects or -methods within the action-routines in my
|> : lex-file.
|>
|> Except that something does. You are not allowed to place a class object
|> that has a constructor in a union.  The items on the yacc parse stack
|> are unions, so this severely restricts allowable use of C++.

    Then you can use pointers. Parsers frequently want to dynamically
allocate nodes anyway.

    Jon
    __@/




Author: tkacik@adtaz.sps.mot.com (Tom Tkacik)
Date: Wed, 8 Sep 1993 01:42:24 GMT
Raw View
In article 17204@vedge.com, hendrik@vedge.com (Hendrik Boom) writes:
>USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
>: In article <1993Sep2.131346.23278@newsserver.rrzn.uni-hannover.de>
>: stohmann@imes.uni-hannover.dbp.de (Joern Stohmann) writes:
>: >Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
>: >or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?

>: Why don   t you use lex & yacc? I   m writing on a grammar-parser (a parser, which
>: converts any given grammarfile into a c++-class-hierarchiy and a new grammar,
>: which puts the parsed grammar objects back on the parser stack instead of
>: int-values). Of course, after yacc-ing, I got plain C-code. But nobody stops
>: me from calling c++-objects or -methods within the action-routines in my
>: lex-file.
>
>Except that something does.  You are not allowed to place a class object
>that has a constructor in a union.  The items on the yacc parse stack
>are unions, so this severely restricts allowable use of C++.

Yacc does not require that the items on its parse stack be unions.  That is common
because there is not much else to do with C.  Yacc uses a #define to identify
the type you want the stack to be.  It actually defaults to int.

When using yacc with C++ I typically use "#define YYSTYPE Node*".
Node is a base class.  Other derived classes can be used to get all of the
needed types (that would normally be inside yacc's union).

It works quite well.

The real problem is getting yacc to produce code that can be compiled with a
C++ compiler.  I use byacc, and modified the skeleton to be C++ compatible.
Flex seems to do ok out of the box.

I do not write C code for the action routines, I write C++, so there is no
problem mixing the two.

Tom Tkacik
adtaz.sps.mot.com






Author: hendrik@vedge.com (Hendrik Boom)
Date: Tue, 07 Sep 1993 20:02:11 GMT
Raw View
USER@zew.zew-mannheim.de (Michael Luebbeke) writes:
: Hi,
:
: In article <1993Sep2.131346.23278@newsserver.rrzn.uni-hannover.de>
: stohmann@imes.uni-hannover.dbp.de (Joern Stohmann) writes:
:
:
:
: >Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
: >or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?
:
:
: Why don   t you use lex & yacc? I   m writing on a grammar-parser (a parser, which
: converts any given grammarfile into a c++-class-hierarchiy and a new grammar,
: which puts the parsed grammar objects back on the parser stack instead of
: int-values). Of course, after yacc-ing, I got plain C-code. But nobody stops
: me from calling c++-objects or -methods within the action-routines in my
: lex-file.

Except that something does.  You are not allowed to place a class object
that has a constructor in a union.  The items on the yacc parse stack
are unions, so this severely restricts allowable use of C++.

:
: There is a more object-oriented BISON-like substitute on PD, called WACCO.
: I   ve installed it, but after a first look on it, I still worked on with bison
: & flex, because the c++grammar I use (Roskinds c++5.y) would have to be
: complety rewritten.
:
: If you got other proposals to use C++ in lex & yacc, please let me know.
:
: Ciao
:
: Miachel Luebbeke
:
:  fam-edv@zew-zew-mannheim.de
: fb49@rummelplatz.uni-mannheim.de
:
: I   m on holiday in September, so if you like me to read your answer to this
: posting, please send a copy vie e-mail to me. Thanks.
:
:
: >-------------------------------------------------------------------------------
:
:
:
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik




Author: kanze@us-es.sel.de (James Kanze)
Date: 8 Sep 93 14:47:46
Raw View
In article <1993Sep8.014224.5125@newsgate.sps.mot.com>
tkacik@adtaz.sps.mot.com (Tom Tkacik) writes:

|> The real problem is getting yacc to produce code that can be compiled with a
|> C++ compiler.  I use byacc, and modified the skeleton to be C++ compatible.
|> Flex seems to do ok out of the box.

If you can modify the skeleton, yacc will produce C++ compatible code.
If you cannot, it is still possible to pass the yacc output through a
shell script (typically just 'sed') to modify the generated code.  (I
you are willing to accept a few warnings, this is typically not too
difficult.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung




Author: leech@cs.unc.edu (Jon Leech)
Date: 8 Sep 1993 11:44:06 -0400
Raw View
In article <KANZE.93Sep8144746@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>If you can modify the skeleton, yacc will produce C++ compatible code.
>If you cannot, it is still possible to pass the yacc output through a
>shell script (typically just 'sed') to modify the generated code.  (I
>you are willing to accept a few warnings, this is typically not too
>difficult.)

    I'm sure there are systems where you need to modify the skeleton, but
this doesn't include the yaccs being shipped by HP, Sun, DEC, IBM, or SGI,
which doesn't leave much.
    A few extern "C" declarations for the helper routines in liby suffice
for these platforms.




Author: stohmann@imes.uni-hannover.dbp.de (Joern Stohmann)
Date: Thu, 2 Sep 1993 13:13:46 GMT
Raw View
Hi,

We want to write a parser. While using the language C , we could use standard UNIX
tools like

 yacc and
 lex.

Now we decided to go with C++.

My question:

Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?


Waiting for your answer,

Joern!

-------------------------------------------------------------------------------

Dipl.-Ing. Joern Stohmann  Institute for Microelectronic Systems
email: stohmann@imes.uni-hannover.de  University of Hanover
Phone : +49 511 762 -3017              Callinstrasse 34
Fax   : +49 511 762 -4994  30167 Hanover
     Germany

-------------------------------------------------------------------------------






Author: USER@zew.zew-mannheim.de (Michael Luebbeke)
Date: Fri, 3 Sep 1993 16:54:10
Raw View
Hi,

In article <1993Sep2.131346.23278@newsserver.rrzn.uni-hannover.de>
stohmann@imes.uni-hannover.dbp.de (Joern Stohmann) writes:



>Are there any UNIX tools like yacc and lex availible for C++ , which generate C++ code
>or allow to include routines written in C++ , so that's possible to pass the whole stuff to a C++ compiler ?


Why don4t you use lex & yacc? I4m writing on a grammar-parser (a parser, which
converts any given grammarfile into a c++-class-hierarchiy and a new grammar,
which puts the parsed grammar objects back on the parser stack instead of
int-values). Of course, after yacc-ing, I got plain C-code. But nobody stops
me from calling c++-objects or -methods within the action-routines in my
lex-file.

There is a more object-oriented BISON-like substitute on PD, called WACCO.
I4ve installed it, but after a first look on it, I still worked on with bison
& flex, because the c++grammar I use (Roskinds c++5.y) would have to be
complety rewritten.

If you got other proposals to use C++ in lex & yacc, please let me know.

Ciao

Miachel Luebbeke

 fam-edv@zew-zew-mannheim.de
fb49@rummelplatz.uni-mannheim.de

I4m on holiday in September, so if you like me to read your answer to this
posting, please send a copy vie e-mail to me. Thanks.


>-------------------------------------------------------------------------------