[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
better.
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").
art
---- junk.y ----
%language "C++"
%no-lines
%union{
int everything;
}
%token interesting
%%
boring : interesting ;
---- junk.tab.hh
namespace yy
{
class parser
{
public:
#ifndef YYSTYPE
union semantic_type
{
int everything;
};
#else
typedef YYSTYPE semantic_type;
#endif
};
} // 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
Hi!
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
> YYSTYPE.
>
> 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.