[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: YYSTYPE needs to be defined and moved

From: Arthur Schwarz
Subject: Re: YYSTYPE needs to be defined and moved
Date: Wed, 27 Nov 2013 14:25:29 -0800 (PST)

bison 2.7.1
flex 2.5.37

Hi Akim;

Thanks for taking the time to write. 

Here's my problems. I have a C++ project and to support input I've decided to 
use bison and flex. Bison seems fairly straightforward but confusing. Flex 
seems fairly straightforward but confusing. Integrating seems to be a nightmare.

The issue here is that in setting the language too C++ in bison, the bison 
interface x.tab.h file buries %union in class parser but does not define 
YYSTYPE. This poses a problem when interfacing with flex.

As to your comment about using 'bison -d'. This is the interface generated with 
junk.y. junk.tab.hh has been stripped of everything not necessary to describe 
the problem. And note that in class parser if YYSTYPE is not defined, it 
doesn't get defined and/or a typedef is not created. But if YYSTYPE is defined, 
then a typedef is created with semantic_type. 

My request is to change the output so that YYSTYPE always has a value.

My integration difficulties with flex and bison are many. flex %bison-bridge 
does something, I don't quite know what but it doesn't integrate well. At the 
same time when I tried %option C++ (to generate a C++ file) it also didn't 
integrate well,  and if I rmember correctly, there were compiler errors. At the 
same time when I generated a flex C file and compiled with a C++ compiler 
(which the flex manual says should work) it had errors. Bison seems to do 

I have a C++ project. One element of the project (only one) leads me to try to 
use flex and bison. I use flex because (by gosh and by golly) it's tedious to 
develop a scanner, particularly a scanner which includes floating point numbers.

I know, and have tried, a C to C interface and it seems to work just fine. It's 
just that in developing a C++ to C++ interface the world turns to dust and all 
are thirsty.

So after this rant (and rave) can you offer some direction forward? Do I have 
to hand-tailor the interface? (And I do use "bison -d").


---- junk.y ----
%language "C++"
   int everything;
%token interesting
boring : interesting ;

---- junk.tab.hh
namespace yy
  class parser
#ifndef YYSTYPE
    union semantic_type
      int everything;
    typedef YYSTYPE semantic_type;

}                // yy

From: Akim Demaille <address@hidden>
To: Arthur Schwarz <address@hidden> 
Cc: "address@hidden" <address@hidden> 
Sent: Wednesday, November 27, 2013 7:13 AM
Subject: Re: YYSTYPE needs to be defined and moved


Le 21 nov. 2013 à 15:01, Arthur Schwarz <address@hidden> a écrit :

> Most particularly, if the flex option %option bison-bridge is used and 
> YY_DECL is not defined, then the following code is generated (using %option 
> prefix="Slip"):
> extern int Sliplex \
>                (YYSTYPE * yylval_param );

I know nothing about Flex's bison-bridge, I have to idea if it
works properly.

> which makes Sliplex available to yyparse but requires direct visibility to 
> My though is that the actual code generated by bison should be in the 
> file/global scope of y.tab.hpp and not located in a class and that YYSTYPE 
> should always be generated. As seen in the example below, it is not always 
> generated.
> In y.tab.hpp the definition of YYSTYPE is placed in the class parser as 
> follows:
> In the parser input file Slip.y the following appears:
>  %file-prefix "Slip.bison"
>  %language "C++"
>  %name-prefix "Slip"
>  %output "Slip.Bison.cpp"
>  %union {
>    int   everything;
>  }
> Which causes the generation of (without #lines) is:
> namespace Slip {
>   /// A Bison parser.
>   class parser
>   {
>   public:
>     /// Symbol semantic values.
> #ifndef YYSTYPE
>     union semantic_type
>     {
>    int   everything;
>     };
> #else
>     typedef YYSTYPE semantic_type;
> #endif 

If you want to export your types, then you really need to generate
the header (see -d in the Bison documentation), and include this header
from that scanner.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]