Re: %union in Bison

"Davide Rizzo" <belgioioso@libero.it> wrote:


>I need to use a customized type definition in Bison; I tried the following
>%{
> #include <string>
> ...
>%}
>
>%union{
> string str;
> int integer;
>}
>
>but even if Bison correctly generate C code defining YYSTYPE with
>typedef union{
> string str;
> int integer;
>} YYSTYPE;
>when I try to compile (Dev-C++ gcc compiler) I get a "member `class string
>{anonymous union}::str' with constructor not allowed in union" error. I
>suppose I can't use classes in unions, but I would like to be sure of that
>(or is it just a string particular mood?)
>thanx for your help, regards


These kind of questions are best answered at the Help Bison list:
    Help-bison@gnu.org
      http://mail.gnu.org/mailman/listinfo/help-bison


-- Also, see below.


>[Bison generates C code, not C++ code. -John]


This is a truth with some modifications:


In the past, when Bison only had C support, its skeleton file was written
so that the parser source code it generates compiled under C++. However,
there turned out to be some problems with that approach:


One is the problem indicated above that Bison implements %union with a
C/C++ union construct. Then, under C++, it is not legal to have classes
with a non-trivial constructors in a union, and the reason to use C++ is
just often that one wants to use such classes (like std::string). So Bison
and %union is currently not very useful, at least not if one wants to use
such classes.


The workaround that I use is to instead write a C++ polymorphic class (a
class object with a pointer that dynamically moves over the other classes
one wants to use). Then one can hook it up so that one gets an exception
thrown if there is a type incompatibility at runtime. Then the %union
feature is not needed so much, because one get type checks at parser time.
It would perhaps be better to have it at Bison compile time, as with
%union, but I have found this approach acceptable.


Another problem with the Bison compile C as C++ approach was that the C
dynamic stack that were implemented did not respect C++ dynamic copying,
which involves some copy constructors. The way around this is to use as
parser stack a genuine C++ container, like std::vector or std:deque, etc.


In order to facilitate that and other multi-language output, Bison has now
been extended with M4: Bison outputs M4 macros, which are fed through M4
and then produces the parser output files.


So current Bison has some C++ skeleton file, intended to work only with Bison.


I could however not get it to work, so I wrote my own C++ skeleton files.
In order to that, though, I had to teal Bison itself: Under C++, there are
a few more places to put the code, in addition to the sources, in the
header, before, in and after the class. It becomes even more complicated
when trying to combine with Flex and produce a proper C++ dogma setup.


So that is the point where the matter seems to be right now: There is some
half-way genuine C++ support in current Bison.


    Hans Aberg * Anti-spam: remove "remove." from email address.
                                    * Email: Hans Aberg <remove.haberg@member.ams.org>
                                    * Home Page: <http://www.math.su.se/~haberg/>
                                    * AMS member listing: <http://www.ams.org/cml/>

Return to the comp.compilers page.
Search the comp.compilers archives again.